>>271
個人的な感想ですが、担当者レベルだと、ひたすら、
ビジネスロジックを設計（詳細設計）して書く、
そして、コーディング規則は現場によって違うけど、
厳しい方が後々良い。けど、書いているときはすごく面倒。
で、大体、テンプレート（見本のソース）を誰かが作ってくれて、
それを、自分のビジネスロジックに合わせて記述する。

ビジネスロジック意外の定番のロジックは大抵、
テンプレートを先輩が作っておいてくれるから、
C言語的には、基本は知っておけば良い。
っていうか、ポインタ程度の理解はすごい重要。
で、よほど、性能を優先する処理以外は、
「他の人がメンテナンスしやすい（理解しやすい）処理を書く」が
基本、というのが自分の大昔の大雑把な経験。

他の人（後任）が理解できない記述やロジックは嫌われる。
もちろん、処理速度を優先する場合は仕方ないけど・・・。