アカウント名:
パスワード:
他人の書いたソースコードを読むのがかったるいのがJavaこの20年間Java自身も改良されてるけど根本的に治らないから無理
10年前に書いた自分のコードですら読むのがかったるいです。
10日前に書いた自分のコードを読むのもかったるいです。
メモリ解放書かなくて良いCみたいな使われかたしてる問題もあるかと。。main以外禁止とか、コピペとか。
オブジェクト指向、Javadocでのドキュメント一元化を全力否定した使い方の多さときたらね。。
メモリ解放は書かなくてもいいけどファイルのクローズとかは結局書かなきゃいけないんだよなあ(Java 7のtry-with-resourcesでだいぶ改善されたけど)。
try-with-resourcesに慣れると旧Javaで書くのが億劫になる。まだまだJava 6で書かないといけない現場も多いのに。
後付けだから仕方ないんだけど、欲を言えば例えばtry(@Closing("disconnect")Client client=new Client(ip,port){ dosomething();}なんて感じで、close系以外のfinallyで呼ぶべきメソッドを指定できるといいなと。
関数がオブジェクトじゃないJavaで不可避なのはわかるが、文字列は嫌だなあ。
他人の書いたソースコードが解読不可能な言語に比べるとまだましなんじゃないの?C++ハカーが作ったtemplateの嵐とか、perlハカーが作ったひたすらワンライナーなコードは、人間には解読不能に近い。これを解読して動作するんだからコンパイラやインタプリタの言語処理系はすごいよ。
C++の自前テンプレートはやっかいですよね。使ってはいけないケースが明示的であればいいのですが、まあそんなこともなく。
正規表現も本当に間違いなく動くのかどうか結局試さないと不安だったりしますよね。
自分はラムダ式になんかもやもやするものを感じるのですが、最近ようやく分かった理由が人間の視覚からの情報が削られすぎていて、何が補完されているのかをいったん考える必要がある点。書いているときはまだいいんですけれどね。3日もすると大変な思いをする。私のような半端者と違ってラムダ式を使いこなすような人は余計なタイプをしたくないという人だったりもするわけでコメントを残すはずもなくより大変なことに。
人間の視覚からの情報が削られすぎていて、何が補完されているのかをいったん考える必要がある点。
頭の中で既存の文法に変換して読んでいるせいではないですかね。あとは、そのコードに可読性への配慮がないという本質的な問題があるのではないかと。
常に優位とは言いませんが、ラムダ式自体が読み辛いという事は無いと思います。僅かなmap(Select)操作をしたいだけなのに、冗長なforeachに展開したり、コードの別の位置に視点を飛ばされる方が思考の妨げになるかと。
ラムダ式を使いこなすような人は余計なタイプをしたくないという人だったりもするわけでコメントを残すはずもなく
アルゴリズムのみの記述で、その内容や目的が語られていないのならば宜しくないですね。
そ、そうなんですか? 麻宮センセー?
アセンブラはともかくコンパイラはな~んも考えてないんではないかと。
あくまで言語構造として考えるのならBeansとかの書き方は合理的ではないって価値観が導き出されてもおかしい話でもないと思う。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
開いた括弧は必ず閉じる -- あるプログラマー
Javaはタイプ量が多い (スコア:0)
他人の書いたソースコードを読むのがかったるいのがJava
この20年間Java自身も改良されてるけど根本的に治らないから無理
Re: (スコア:0)
10年前に書いた自分のコードですら読むのがかったるいです。
Re: (スコア:0)
10日前に書いた自分のコードを読むのもかったるいです。
Re: (スコア:0)
メモリ解放書かなくて良いCみたいな使われかたしてる問題もあるかと。。
main以外禁止とか、コピペとか。
オブジェクト指向、Javadocでのドキュメント一元化を全力否定した使い方の多さときたらね。。
Re: (スコア:0)
メモリ解放は書かなくてもいいけどファイルのクローズとかは結局書かなきゃいけないんだよなあ(Java 7のtry-with-resourcesでだいぶ改善されたけど)。
Re: (スコア:0)
try-with-resourcesに慣れると旧Javaで書くのが億劫になる。
まだまだJava 6で書かないといけない現場も多いのに。
後付けだから仕方ないんだけど、欲を言えば例えば
try(@Closing("disconnect")Client client=new Client(ip,port){
dosomething();
}
なんて感じで、close系以外のfinallyで呼ぶべきメソッドを指定できるといいなと。
Re: (スコア:0)
関数がオブジェクトじゃないJavaで不可避なのはわかるが、文字列は嫌だなあ。
Re: (スコア:0)
他人の書いたソースコードが解読不可能な言語に比べるとまだましなんじゃないの?
C++ハカーが作ったtemplateの嵐とか、perlハカーが作ったひたすらワンライナーなコードは、人間には解読不能に近い。
これを解読して動作するんだからコンパイラやインタプリタの言語処理系はすごいよ。
Re: (スコア:0)
C++の自前テンプレートはやっかいですよね。
使ってはいけないケースが明示的であればいいのですが、まあそんなこともなく。
正規表現も本当に間違いなく動くのかどうか結局試さないと不安だったりしますよね。
自分はラムダ式になんかもやもやするものを感じるのですが、最近ようやく分かった理由が人間の視覚からの情報が削られすぎていて、何が補完されているのかをいったん考える必要がある点。書いているときはまだいいんですけれどね。3日もすると大変な思いをする。
私のような半端者と違ってラムダ式を使いこなすような人は余計なタイプをしたくないという人だったりもするわけでコメントを残すはずもなくより大変なことに。
Re: (スコア:0)
人間の視覚からの情報が削られすぎていて、何が補完されているのかをいったん考える必要がある点。
頭の中で既存の文法に変換して読んでいるせいではないですかね。
あとは、そのコードに可読性への配慮がないという本質的な問題があるのではないかと。
常に優位とは言いませんが、ラムダ式自体が読み辛いという事は無いと思います。
僅かなmap(Select)操作をしたいだけなのに、冗長なforeachに展開したり、コードの別の位置に
視点を飛ばされる方が思考の妨げになるかと。
ラムダ式を使いこなすような人は余計なタイプをしたくないという人だったりもするわけでコメントを残すはずもなく
アルゴリズムのみの記述で、その内容や目的が語られていないのならば宜しくないですね。
Re: (スコア:0)
Re: (スコア:0)
そ、そうなんですか? 麻宮センセー?
Re: (スコア:0)
アセンブラはともかくコンパイラはな~んも考えてないんではないかと。
Re: (スコア:0)
あくまで言語構造として考えるのならBeansとかの書き方は合理的ではないって価値観が導き出されてもおかしい話でもないと思う。