當前位置：首頁 > 编程语言 > java >内容正文

java

java的网络编程有用吗_十大有用但又偏执的Java编程技术

發布時間：2023/12/3 java 26 豆豆

生活随笔收集整理的這篇文章主要介紹了 java的网络编程有用吗_十大有用但又偏执的Java编程技术小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

java的網絡編程有用嗎

經過一段時間的編碼（以我為例，大約20年左右，當您玩得開心時光飛逝），人們開始接受這些習慣。因為，你知道...

任何可能出錯的事情都會發生。

這就是為什么人們會采用“防御性編程”的原因，即偏執狂的習慣有時會變得很有意義，有時會變得晦澀難懂和/或聰明，甚至在想到編寫者時也會有些怪異。這是我個人列出的十大有用但又偏執的Java編程技術。我們走吧：

1.首先將字符串文字

通過將String文字放在equals()比較的左側，防止偶然的NullPointerException從來不是一個壞主意，如下所示：

// Bad if (variable.equals("literal")) { ... }// Good if ("literal".equals(variable)) { ... }

這是顯而易見的。將表述從次優版本改為好版本不會丟失任何內容。如果我們只有真正的期權，對嗎？不同的討論…

2.不要相信早期的JDK API

在Java的早期，編程一定是一個很大的難題。這些API仍然很不成熟，您可能會碰到如下一段代碼：

String[] files = file.list();// Watch out if (files != null) {for (int i = 0; i < files.length; i++) {...} }

看起來偏執嗎？也許吧，但是閱讀Javadoc ：

如果此抽象路徑名不表示目錄，則此方法返回null。否則，將返回一個字符串數組，該字符串數組用于目錄中的每個文件或目錄。

是的，對。不過，最好確保添加另一張支票：

if (file.isDirectory()) {String[] files = file.list();// Watch outif (files != null) {for (int i = 0; i < files.length; i++) {...}} }

mm！編碼Java列表時，違反了我們的10條最佳最佳實踐中的規則5和6。因此，請做好準備并添加該null檢查！

3.不要相信“ -1”

我知道這很偏執。 String.indexOf()的Javadoc明確指出……

返回此對象表示的字符序列中字符第一次出現的索引；如果未出現字符，則返回-1。

因此， -1是理所當然的，對吧？我說不。考慮一下：

// Bad if (string.indexOf(character) != -1) { ... }// Good if (string.indexOf(character) >= 0) { ... }

誰知道。也許他們需要在某個時間點進行ANOTHER編碼，以便說，如果不區分大小寫地檢查， otherString包含otherString …也許是返回-2的好例子？誰知道。

畢竟，關于十億美元的錯誤，我們已經進行了數十億次討論，這是NULL 。為什么我們不應該開始討論-1 ，它在某種程度上是原始類型int的替代null ？

4.避免意外分配

是的它發生得最好（盡管不是我。請參閱＃7）。

（假設這是JavaScript，但是我們也要對語言保持偏執）

// Ooops if (variable = 5) { ... }// Better (because causes an error) if (5 = variable) { ... }// Intent (remember. Paranoid JavaScript: ===) if (5 === variable) { ... }

再次。如果您的表達式中有文字，請將其放在左側。當您要添加另一個=符號時，您不會在這里偶然出錯。

5.檢查空AND長度

只要有集合，數組等，請確保其存在且不為空。

// Bad if (array.length > 0) { ... }// Good if (array != null && array.length > 0) { ... }

您永遠不知道這些數組從何而來。也許來自早期的JDK API？

6.所有方法均為最終方法

您可以告訴我所有關于您的開放/封閉原則的信息，這些都是胡扯。我不信任您（正確地擴展了我的課程），我也不信任自己（不偶然地擴展了我的課程）。這就是為什么所有未明確打算用于子類型化（即僅接口）的事物都是嚴格final 。另請參閱我們的《編碼Java的10條最佳實踐》列表中的第9條。

// Bad public void boom() { ... }// Good. Don't touch. public final void dontTouch() { ... }

是。這是最終的。如果那對您不起作用，請對其進行修補或檢測，或重寫字節碼。或發送功能請求。我敢肯定，您要覆蓋上述內容并不是一個好主意。

7.所有變量和參數均為最終變量

就像我說的。我不信任自己（不會意外覆蓋我的價值觀）。話雖如此，我一點也不相信自己。因為…

…這就是為什么所有變量和參數也都設為final 。

// Bad void input(String importantMessage) {String answer = "...";answer = importantMessage = "LOL accident"; }// Good final void input(final String importantMessage) {final String answer = "..."; }

好吧，我承認。盡管我應該這樣做，但我確實很少經常申請。我希望Java像Scala一樣正確，人們只需在各處輸入val ，甚至都無需考慮可變性-除非他們通過var顯式（很少！）使用它。

8.重載時不要相信泛型

是。這有可能發生。您相信您寫的是一個超級棒的API，它完全搖擺并且完全直觀，并且隨之而來的是一些用戶，它將所有內容原始廣播到Object直到織補編譯器停止執行，然后突然他們會鏈接錯誤的方法，以為這是您的錯誤（總是如此）。

考慮一下：

// Bad <T> void bad(T value) {bad(Collections.singletonList(value)); }<T> void bad(List<T> values) {... }// Good final <T> void good(final T value) {if (value instanceof List)good((List<?>) value);elsegood(Collections.singletonList(value)); }final <T> void good(final List<T> values) {... }

因為，您知道……您的用戶，他們喜歡

// This library sucks @SuppressWarnings("all") Object t = (Object) (List) Arrays.asList("abc"); bad(t);

相信我。我已經看到了一切。包括像

偏執是很好的。

9.始終打開默認開關

切換...這些滑稽的陳述之一，我不知道該敬畏地嚇呆還是哭泣。無論如何，我們被switch困住了，所以我們最好還是在需要的時候把它弄對。即

// Bad switch (value) {case 1: foo(); break;case 2: bar(); break; }// Good switch (value) {case 1: foo(); break;case 2: bar(); break;default:throw new ThreadDeath("That'll teach them"); }

因為將value == 3引入軟件的那一刻，它一定會來！而且不要說enum ，因為它也會發生在enums ！

10.用花括號切換

實際上， switch是最醉人的說法，任何人在喝醉或打賭時都被允許進入一種語言。考慮以下示例：

// Bad, doesn't compile switch (value) {case 1: int j = 1; break;case 2: int j = 2; break; }// Good switch (value) {case 1: {final int j = 1;break;}case 2: {final int j = 2;break;}// Remember:default: throw new ThreadDeath("That'll teach them"); }

在switch語句中，所有case語句之間僅定義了一個作用域。實際上，這些case語句甚至不是真正的語句，它們就像標簽，并且switch是goto調用。實際上，您甚至可以將case語句與令人驚訝的FORTRAN 77 ENTRY語句進行比較， FORTRAN 77 ENTRY語句的神秘之處僅在于其強大功能。

這意味著無論我們是否發出break ，都會為所有不同情況定義變量final int j 。不是很直觀。這就是為什么通過一個簡單的block在每個case語句中創建一個新的嵌套作用域始終是一個好主意的原因。（但不要忘記塊內的break ！）

結論

偏執狂編程有時看起來很奇怪，因為代碼往往比實際需要的更為冗長。您可能會想，“哦，這永遠不會發生”，但是正如我所說。經過20年左右的編程，您只是不想修復僅由于該語言太老又有缺陷而導致的那些愚蠢的，不必要的小錯誤。因為你知道

現在輪到你了！

您在編程中最偏執的怪癖是什么？

翻譯自: https://www.javacodegeeks.com/2015/08/top-10-useful-yet-paranoid-java-programming-techniques.html