コーディングについて

Question

仕事でプログラマ兼雑用をしております。
事務職志望だったのがなぜかシステム開発部に異動となり、
知識が全く無いため、色々とご教示頂きたいと思っております。

①綺麗なコードの定義と、汚いコードの定義を
サンプルと共にご教示いただけませんでしょうか。
また、皆様がコーディングの際に気を付けている事、
心がけている事などもご教示頂きたいです。

②コーディングのスキルは、どのように向上させましたか？
また、教えてくれる先輩や上司が全くおらず、
コードの見直しなども一切行って頂けない場合、
どの様に自分のコードをブラシアップ(？)すれば良いでしょうか？

③プログラマになって良かったこと、悪かったことはありますか？

様々な方のご意見、ご指導をお願いしたいと思っております。
どうぞよろしくお願いいたします。

Answer 1

①
たくさんありすぎて例示するのは難しいですね。
言語によっても違うルールがありますので、まずは検索してみたほうが良いでしょう。

心掛ける点については、どんなルールが良いかどうかよりも
「ルールを統一する」ことに注目するのが良いですね。
少なくとも同じプロジェクト内ではコーディングルールは統一すべきです。
主観ですが、統一感の無いコードは「汚い」と感じます。

それと、takayukiinabaさんの挙げられている「修正・履歴コメント」は非常に同意します。
最新のソースコードに無駄な情報は残すべきでは無いと思います。

②
私もほとんど師匠がいない中でやってきましたが、
技術書で学べることも多いです。
例えば、
ライティングソリッドコード―バグのないプログラミングを目指して
が少し古いですが有名です。このページの関連書籍（Code Complete）も良いですね。

また、今は GitHub のようにOSSのソースコードを見る環境が整っていますので、
評判の良い、または人気のある（Starの数が多い）OSSのソースコードを読んでみるのがおすすめです。

そして、これらを参考にしてご自分でたくさんコードを書いてみることです。

以上のようにすれば、独学でもブラッシュアップのさせ方を学んでいけると思います。

1万時間の法則というのはご存知ですか？
熟練者になるには時間がかかりますが、とにかく練習あるのみです。

③
良かったことは、比較的自分がやりたい仕事をできているということ。
悪かったことは、炎上案件に駆り出されたこと。

やりたくない仕事をすることもありますが、
仕事に関係なく、プログラマーは好きでやっていますね。

Answer 2

コーディング規約に則った統一的な記述がされたコードはキレイに見えます。
末尾コメントを乱用したり、無駄に空行が多かったり、コメントを付けることを意識しすぎて余計なコメントを大量につけてしまっているものは汚いコードに見えます。
深いネストがあるコードは汚く見えます。

オライリーの「リーダブルコード」を読んでみると良いと思います。

地道に経験を詰むしかないと思います。OSSのコードを読んでみるのは近道になるかもしれません。

自力で簡単なツールをサクッと作れるのは良いですよね。
使うツールにこだわりを持ちすぎて環境改善に時間をかけすぎてしまうプログラマは多いのでは…。これはプログラマ特有の悪い癖な気がします。

Answer 3

1. 綺麗なコード

• 一つのメソッドが長すぎない
• コードをパッと見てやりたいことが分かり、簡潔に書かれている
• 同じようなコードが複数箇所に出てこない（処理が共通化されている）
• 互換性の為に残されている古いライブラリや型が使われていない（Webからのコピペ等で起きやすいが、大抵新しい書き方の方が簡潔で高性能）
• 他の回答者の方もおっしゃっているように余分な改定履歴のようなコメントがないこと

例示出来そうなものは後ほど追記しようと思います。

1. とにかくたくさんコードを書いたほうがいいと思います。そして、前に書いたコードを見ると直したい箇所が出てくるはずです。そこでリファクタリングを行いましょう。いきなり綺麗なコードを書くより、前よりすこしでも綺麗なコードを書くほうが簡単だし、自分の成長も実感できると思います。

良かった点

• （基本的には）仕事が楽しい
• 開発したシステムの利用者に感謝された時の嬉しさ

悪い点

• 眼の疲れ、肩こり

Answer 4

始めまして、nhさん。

独学で勉強してフリーランスで生活をしているプログラマーです。
周りに相談できる人がいなかった状態というのは同じですので、
アドバイスになれば、と思い回答させていただきます。

①綺麗なコードの定義と、汚いコードの定義を
サンプルと共にご教示いただけませんでしょうか。
また、皆様がコーディングの際に気を付けている事、
心がけている事などもご教示頂きたいです。

こちらに関してなのですが、汚いコード、綺麗なコードというのは
実は一概に言うことができないのがプログラミングなのです。

たとえば奇数・偶数を判定するプログラムを書くときに以下のような書き方があります。
※0に関しては今回は無視しております。

<?php
  $n = mt_rand();
  if($n % 2 == 0){
    printf("%dは偶数です",$n);
  }else{
    printf("%dは奇数です",$n);
  }
?>

このコードに関しては、きっと綺麗でもなく汚いわけでもなくきっと普通のコードだと思われます。

<?php

// 乱数を生成
$n = mt_rand();

// $nが偶数の場合
if($n % 2 == 0)
{
  printf("%dは偶数です",$n);
}
// $nが奇数の場合
elseif($n % 2 == 1)
{
  printf("%dは奇数です",$n);
}
?>

たとえば最初のコードをこのように書き換えます。
改行の位置を変えたり、コメントを加えたことにより、
プログラムの可読性があがったように感じると思います。
ここまで書くと「おっ、きれいじゃね？」と思う人も多いのですが、
if文の後の中括弧を改行するのを嫌う人も中にはいます。
if-else文の途中にコメントを入れるのを嫌う人もいます。

このように人によって、nhさんの場合ですと会社・部署によって
コーディングの規則というものがある場合が多く、それに則ったプログラムが
一番綺麗なプログラムといえるのではないかと私は考えております。

気にしている点なのですが、私はフリーでプログラマーをやっておりますので、
企業であったり、個人であったりいろいろな方にソースを納品することがありますので、
コーディング規則、などを意識するのではなく、コメントの入れ方やオブジェクト指向の
導入などをし、可読性を高めるよう気をつけております。

②コーディングのスキルは、どのように向上させましたか？
また、教えてくれる先輩や上司が全くおらず、
コードの見直しなども一切行って頂けない場合、
どの様に自分のコードをブラシアップ(？)すれば良いでしょうか？

上記のように、概念としてお伝えはしましたがプログラマーでもない方を
システム開発部へ異動させている時点で人手の足りなそうな感じもします。

ですので、一応先輩・上司にコーディング規則について尋ねてみて、
もし、ないようでしたらネットでいろいろ検索してみたり、
技術書を購入して読んでみたりすることをオススメいたします。

③プログラマになって良かったこと、悪かったことはありますか？

これに関してなのですが、私自体すこし特殊でプログラミングが大好きで
プログラマになったので、プログラマになったこと事態がそのまま良い事なのかもしれません。笑

それ以外で、メリットとしてあげられるので、最も大きい点は
こういうアプリ欲しいなとか、こういうツール欲しいなとか、こういうサービス欲しいなというときに
「じゃあ、つくっちゃえ！」と自分で開発ができる点だと思います。

悪い点としては、私がフリーだからなのですが(プログラマでは多数派だと思いますが)
一般の方と比べて、完全に夜型人間になってしまって、周囲の人と
生活リズムが合わなくなってしまう点ですかね。笑

あとは、デスクワークで動かなくなりますので、体重の増加も
気をつけたほうがよろしいかと思います。笑

以上、私個人の考えですが回答させていただきました。

この業界、いろんな方がおりますので、是非いろんな方の意見を聞いて
自分の知識として蓄え、精進していったください！

Answer 5

①綺麗なコードの定義と、汚いコードの定義を
サンプルと共にご教示いただけませんでしょうか。
また、皆様がコーディングの際に気を付けている事、
心がけている事などもご教示頂きたいです。

→綺麗なコーディングと汚いコーディングの定義についですが、単純に言ってしまうとインデント（字下げ）がされてるか居ないかではないでしょうか？
私の経験上、ツール等を利用して作成されたHTMLなどは、左側に整列されていて読みにくいと感じた事は多々あります。

また、もう一点は追記・改修の履歴がコメントアウトされて残されているパターンではないかと思います。
ファイル履歴管理ツール（GithubやSVN）を利用しているのであれば追記・改修の履歴が記録されているため、プログラム上にコメントアウトで残しておく必要がない為、このような記述が残っているとプログラムが読みにくくなると思います。

②コーディングのスキルは、どのように向上させましたか？
また、教えてくれる先輩や上司が全くおらず、
コードの見直しなども一切行って頂けない場合、

→コーディングのスキルを向上させるには、ひたすらコードを書く、他の人が作成したプログラムを読んで理解するのみではないかと・・・・

どの様に自分のコードをブラシアップ(？)すれば良いでしょうか？

自分でやりたい事をまずプログラムしてみて、同じ事をしている人のサンプルソースと比較してみるなど。
プログラムは、十人十色なので結果は同じでもプログラム方法は各々異なります。
その為、その中で良いところ悪いところを発見し自分のコーディングスキルを向上させるのみです。

③プログラマになって良かったこと、悪かったことはありますか？

良かった事・・・・。
プログラムで詰った時に、それを解決した後の満足感・達成感は癖になるかも知れないです。

悪かった事・・・・。
ほとんどが裏方ということ・・・。
同業者以外その辛さを理解してくれないという点でしょうか・・・。

Answer 6

①綺麗なコードの定義と、汚いコードの定義を
何が良いかは一概には難しいですが、何にせよコーディング規約を決めてルールにのっとって
書くのが望ましいです。
統一されたルールで書かれたソースはやはり読みやすいため綺麗なコードといえるのではないでしょうか？

②コーディングのスキルは、どのように向上させましたか？
教えてもらう環境がない場合
初心者からの脱出は、何らかの教本を読破して理解することかと思います。
ある程度できるようになったら、他人のコードを読むのが一番ではないかと思います。
今はオープンソースのアプリがたくさんありますので、そういったものを読んでみるのをお勧めします。

③プログラマになって良かったこと、悪かったことはありますか？
良かったことは、完成した時の達成感とお客様からの感謝の言葉ですかね？
悪かったことは、仕事が大変なことですね

Answer 7

個人的に綺麗ではないと思うこと（反対が綺麗なコードになります）

• インデントがされていない
• コードで実現しようとしていることがわかりづらい
• 保守しづらい（バグ対応、機能追加がしづらい）

コードを書く際にきをつけていること

• 保守しやすい（バグ対応、機能追加がしやすい）コードを書くように
• ロジックをわかりやすく
• 意味不明なコメントを書かない

コーディングスキルの向上

• サンプルコードを見ながら、同じものを自分で書いてみる
• サンプルのアプリの機能追加変更をしてみる
• サンプルで覚えた方法を使って、自分で何かアプリを作ってみる
• きたないコードを自分でリファクタリングしてみる

ブラッシュアップ

• 一般的に綺麗と言われているソースコードを読んでみる
• リファクタリングやアンチパターンの勉強をする

プログラマになって良かったこと
自分で利用するアプリを自分で設計して、作って、使うことができるのが良いですね。

プログラマになって悪かったこと
プログラマ自体が悪かったと考えたことは、あまりなかったです。

Answer 8

昔、某H社にいた頃の尊敬する先輩のコードは、main() 関数にマクロ1行。あとは全部ヘッダファイルに。
ブレークポイントが1個しか設定できないのにデバッグできないでしょ、って言ったら脳内変換でデバッグ済みと。その方の担当はかなり特殊な分野ですが、苦情無しと聞いていました。
だれも読めないし理解もできない。でもちゃんと仕様通りの動作。

上の方と食い違いますが、きゅうきょくのシンプルは実は読みにくいのですよ。あっちこxち断片コードを脳内変換で組み立て直すよりは、馬鹿のひとつ覚えな、1メソッド3000行の方が全体像の把握がし易い場合もあります。

纏めたほうがいい処理、まとめないで可能な限り仕様書に近い書き方、今後チームでやってく場合はこういう局面がいくつも出てきます。要は慣れ、慣れるために、何が良いコードで何が悪いのかは経験が解決してくれます。

Answer 9

①綺麗なコードの定義と、汚いコードの定義
これはどう捉えるかで変わると思います。
質問内容が「綺麗に見える整ったコード」というものであれば、以下の様な感じです。
・定められた規約に従ったコード
・同じようなルール、実装に乗っ取ったコード

これを「いい設計を行っているコード」と捉えると全然違うものになると思います。
・同じロジックが一切出てこないコード
・if文、ループが極限まで単純化されているコード
・とにかくとても短いコード（構文で誤魔化して見かけ上だけ減っているものは除外）

オブジェクト指向を突き詰めていくとアルゴリズムで書いた部分の大半は分離できるようになります。
クラスは増えますが、1モジュール内のコード量はどんどん減っていきます。
特殊な計算をするアルゴリズムとかでない限り、1モジュール内が極限までシンプルになっているのが理想と考えています。

②コーディングのスキルは、どのように向上させましたか？
・ソフトウェアの設計方法をきちんと学ぶ（書籍、実際のコードなどで）
・自分の書いたコードを見なおし、反省点を挙げ次回に反映
・最新の設計方法などを追いかけ、実践してみる
これを何十年も繰り返しています。

③プログラマになって良かったこと、悪かったことはありますか？
・良くも悪くも自分の実力が結果に直結出来るところ
・概念さえ作ることが出来れば、大抵のイメージしたものが作れてしまうところ

言語によりますが、現実世界では制約が多すぎて出来ないことでもソフトの上では何とかなる可能性が大きいのはとても魅力的です。

Answer 10

1.綺麗なコード
読む人が詰まる事なく読める事が綺麗なコードだと思います。日本語の文章で言うと、変な改行や変な名前、変な文章のまとまり等がない事
これが基準ラインです、これ以下だと汚いコード、これ以上だと綺麗なコードです。
さらに、特定の集団や組織内で決められたコーディングルールが存在します。このルールによって基準ラインは上昇します。
2.スキル向上
ネットや書籍を使った独学です、厳しいですが一番身につきます。
3.良かった事、悪かった事
良かった事
毎日同じ事を繰り返す事が嫌いなので、毎日違う事ができて良かったと思います。また、自分の努力が技術に直結する事がいいですよね。
悪かった事
プログラミングを魔法みたいに考えていてなんでもできると思っている年輩の方が多いですよね。

Answer 11

1. 仕事の場合はコーディング規約に従ったソースコードであること。

趣味の場合は、実行コストが低く、短いソース、後は仕事で実装する場合と
同じように変数名が統一されているといった具合です。

1. 仕事を通して身に着けるのが一番の近道と考えます。

上司や先輩に薫陶が得られないならば、オープンソースに参加されるのが良いと思います。

1. 良かったことは、欲しいツールが自前で作れること。

悪かったことは、幾度か地獄を見せられたこと。

Answer 12

①
・綺麗なコードはプログラムの流れが読みやすい。
汚いコードは流れが読めないまたは読みづらい。
・変数の命名やプログラミングスタイルが一貫していないのは汚い部類に
入るかも。

コーディングスタイルは、他の人と一貫させるためにある程度の規則を
作ったほうがいいです。
コーディングスタイルでググれば色々出て来ると思います。

②
・とにかく人のコードを読みまくりました。
また、インターネットも無い時代だったので、雑誌などに掲載されていた
プログラムを打ち込んで動かして勉強しました。
今に比べると情報が圧倒的に少ない時代だったので、コードに飢えてました（笑）

③
良かったこと
・物事を論理的に考える癖がついた
・日々新しい情報が出て来るのである意味楽しい。（着いて行くのは大変かも）

悪かったこと
好きでやってる仕事なのであまり思いつきませんが・・・敢えて言うと
1/0の世界なので、一文字間違えただけでも、動かないならまだしも
変な動きや暴走してしまうリスクと隣り合わせのところかな。
仕事の幅を広げるには、色々なことを勉強しないといけないので
年齢を経るに従って大変になってくるという悩みはあります。

Answer 13

①綺麗なコードの定義と、汚いコードの定義
あとで読み返して何をしているのかわからないのが汚い記述です。
プログラミングは、変数と関数で成り立っています。
ですからまず、メインとなる関数内にどのような処理をするのかの
コメントと該当する関数名を記述します。
それからその一つ一つの関数を作成していきます。
それで関数部分で受け継ぐ変数はなんで、返す値は何かを明確にコメントします。
さらにその関数から子関数、があれば、この関数は子関数を使っているということも
明記しておきます。
関数ができあがるとそれはもうブラックボックスと考えて、利用するには変数として
扱います。 また他のプログラムでもこのようにしておけば再利用が簡単になり
能率があがります。 それぞれの言語で用意されている関数も中でどのような
記述（コーディング）で行われているか気にしないですよね？

②コーディングのスキルは、どのように向上させましたか？
プログラムには成功法とアイデア法があり、関数で返す値を得るには、
いろいろな方法があるということを自分で考える、検索するということですね。
たとえば、並べかえの方法では、成功法はバブルアップ法というのがありますが
多量のデータを扱うには時間がかかりすぎます。それでクイックソートとかの
他の方法もあり、それらを理解するとスキルがあがると思います。
プログラムの動きの確認を綿密におこなうということがスキルアップの秘訣です。

③プログラマになって良かったこと、悪かったことはありますか？
自分の置かれている仕事をマルチで行うことができるようになったということです。
つまり、バッチ処理とオンライン処理ですね。 全ての処理を書き出して、期日は
いつまでか、どのくらいの時間でできるか？ 優先順位はどうかというのを
計画できるようになったということです。
悪かったことは、簡単なプログラムを無償で頼まれることですね！

あと、難解なアルゴリズムを苦労して、自分であみ出したとき、
自分で作ったプログラムのコーディングが美しく芸術だと感じたとき、
おれって天才と思ったときなど、
プログラム完成の達成感がたまりません。

Answer 14

①綺麗なコードの定義と、汚いコードの定義
すべてのコーディングの統一感（コーディング規約も含む）ではないでしょうか。
if文など書き方はいろいろありますが、それを統一することで読みやすくなります。
下記はどちらも同じですが、どちらかに統一しておけばコードは読みやすくなります。
（ちょっと極端な例ですが）

if(String.IsNullOrEmpty(hoge) == false)
{
}
if(!String.IsNullOrEmpty(hoge))
{
}

可読性の重視や拡張性の重視も綺麗なコードと言えると思います。

②コーディングのスキルは、どのように向上させましたか？
僕もコードを見直してくれる上司がいませんでした。
最初はひたすら人の書いたコードを読んでいました。
自分の書いたコードを後日読み返し、共通化できるところは共通化したりブラッシュアップを続けました。
あとはいろんなサイトでコーディング規約を読みまくりました。

③プログラマになって良かったこと、悪かったことはありますか？
・良かったこと
いろんな業界の仕事ができる点でしょうか。前日まで飲食系のシステムを組んでいたかと思えば、
翌日から倉庫の在庫管理システムを組んだりと、幅広く仕事をできるのはメリットだと思います。
・悪かったこと
やはり拘束時間が長いことです。それも今ではスキルアップの役に立ったと思ってはいます。

Answer 15

全体としては、
気付き
の問題なのですよね。
気付くか、気付かないか
質問者さんは、気付いてしまった。
⇒気付けない人は、プログラマーや、管理者には向かない。
１を聞いて、１０は知れなくても、２、３位は気付いて欲しい。
コーダーや、サブルーチンプログラマと呼ばれる方々とは違い、
ゼネラリストの面も持つのが本来のプログラマーの姿です。
日本の上流、下流といっている姿とは（ただの搾取の構造）、
違う面が求めらるのに、気付けるかどうか。
’
①私自身は、他人のコードを読むのは苦ではないので（どちらかというと好き）、
統一感があって、明快なコードは、美しいと感じます。
⇒お仕事ですので、規約や規定がある場合は、そっちが優先。
現状変更は、いきなり正論、ごもっとも論を振りかざしても、組織は変わりません。
美しないと思う部分は、徐々に変えていくように、持っていく。
②他人のコードを見る、自身の昔のコードを見る。
（少なくとも、数年は使われるコードを書きますので、
古い赤の他人となった、自分のコード後日みて、ダメじゃんとダメ出ししたりｗ）
時間が経つと、自身のコードを他人の目で見る事ができます。
気分に余裕が出来たり、新たな知見があれば、見えなかった部分が、見える場合もあります。
③物作りの中では、低コストで、作り直しが容易で、結果が直ぐに目で見える。
私には合っているようです。
３．１１以後、マイコン遊び＆電子回路、ラジオ作りを再開したりして、
物がある場合は金かかるなぁと、小遣いでやりくり算段。
一時物作りを止めていたので、実際上の稼ぎにはあまり貢献していません。

Answer 16

... 知識が全く無い...

プログラム言語の勉強と並行して、 実際に使っている OS についても勉強をすることをお勧めします。
Windows, Mac, Linux のどれを使っていますか？あるいは 複数の OS をつかっているのでしょうか？
いずれも簡単な入門書を読むと良いです。

さらに 開発環境についても学んでおくことが必要です。
(単なるテキストエディタをつかっている、 visualStdio, Eclipse のような統合開発環境をつかっている、
ソースコードのバージョン管理は subversiom, git のようなつかっている、...
など、会社・部署・チームで使っている開発環境について慣れることが必要です。
コーディング規約についても上司の方などから説明をうけると良いとおもいます)