Lessons after five years of professional programming

Re:Lessons after five years of professional programming by pyre on Wednesday April 03, 2013 @09:28AM (#5485871)

  > Code should be self readable, and if you get
  > to the point where it isn’t, then you may have
  > to rewrite few bits. This is not always
  > possible though, especially for temporary
  > hotfixes or hacks. In this case, comments are
  > a must.

* Sometimes business decisions may not make logical sense, but someone says "do it this way." It makes sense to comment this in the code.

* The code might tell you what it's doing, but not necessarily why it's doing it.

* You may be making use of legacy components that you are unable to rewrite. It may make sense to comment on their use within newer code that interfaces with them, making it possible for people to bugfix the interface without needing to delve all the way into the legacy component.

[ Parent | on HN ]

Re:Lessons after five years of professional programming by billN on Friday April 05, 2013 @05:56AM (#5497503)

Agree - but ideally these are just few exceptions. If these practices take over, then we may have a bigger issue to deal with and have a look at some serious refactoring of the infrastructure. e.g. too many legacy components may just require some rewriting or, if not possible, some kind of wrappers or facade patterns that makes the behavior self-readable (to the point where the legacy code is used).

[ Parent | on HN ]

Re:Lessons after five years of professional programming by snake_plissken on Wednesday April 03, 2013 @03:16PM (#5488368)

Toes agree. It's the why you are deciding to do something a certain way that's important.

[ Parent | on HN ]