Java には多くの安全機能と制約があり、開発者が小文字でクラス名を開始できるのはなぜでしょうか。そうするのは非常に愚かな考えですが。
それとも、これが役立つケースを見落としていませんか? それとも単にプログラマーをいじめていないだけなのでしょうか?
Java には多くの安全機能と制約があり、開発者が小文字でクラス名を開始できるのはなぜでしょうか。そうするのは非常に愚かな考えですが。
それとも、これが役立つケースを見落としていませんか? それとも単にプログラマーをいじめていないだけなのでしょうか?
多くのことはばかげた考えです - そしてそれらのほとんどはコンパイラによって強制されません.
結局のところ、クラス、メソッド、および変数名の大文字化は慣習の問題であり、これはほとんどの言語に当てはまります。
これまで、プログラミング言語は規約を強制するべきではないと考えられていたためです。しかし、今は状況が少し変わり、Ruby on Rails のような「Conventions over Configuration」アプローチに好都合な雰囲気があります。
したがって、将来的には、プログラミング パターンとベスト プラクティスから生じる規約ベースのプログラミング言語/フレームワークがさらに増える可能性があります。
Perl には、いくつかの (ただしこの特定のものではない) ベスト プラクティスを強制する "use strict" ディレクティブがあります。コンパイルされるコードにこのようなベスト プラクティス規則を強制する -strict オプションを javac に追加してみませんか? これにより、標準に従わない.jarまたは.classライブラリの使用が引き続き許可される可能性がありますが、コンパイルされる新しいもの(.java)に強制されます...または、デフォルトでオンにして、-relaxedディレクティブを提供することをお勧めします強制をオフにすることで、何らかの理由でできない人にペナルティを課すことなく、誰もがより厳密に標準に従うように促します。
JLS がずさんさを許容する方法はいくつかあります。たとえば、修飾子の順序。おそらく最悪の違反はインデントですが、これは文法では適切に処理できません。
クラス名に関する特定の問題は、IIRC の文法では、どの識別子がクラス/インターフェース名で、どの識別子がそうでないかが明確でないことです。宣言ポイントでの厳密性は可能ですが、残りの文法がより複雑になります。
おそらく、それは時間的なプレッシャーに帰着します。当時でさえ、Java は偉そうに考えられていました。あらゆる種類の規則 (通常はライブラリとは異なる) を使用して C および C++ を書くのに忙しく、あらゆる種類の混乱を引き起こしている人々ですが、気にしていないようでした。
おそらくこれの大きな要因は、言語の歴史のどこかでこのようなことを許可したとしても、それを変更して既存のコードを壊したくないということです。