The Perfect Method

After a sabbatical, a video. Enjoy.

Category:

Howto & Style

Tags:

• codingkriggs
• software
• engineering
• perfect
• method
• comments
• testing
• uml
• class
• gravitation
• scope
• list
• bottom
• up
• gut
• pride

[F00dTube]

MY perfect design method would be to design an application as slim as possible, test it and redesign it. Use what code is reusable from the last iteration. Also you if are not commenting that seems to me as keeping a blind eye from the fact that you are going to write bugs and that you are going to make things that you will wish to change. Also your coding style will change with time. And lastly if you work at a company your api will probably be reused by other people.

[codingkriggs]

Yep, all valid points. To clarify, I am not against all comments. TODOs and FIXMEs are ok, for example. I'm against comments that say things that you can gather just by quickly looking at the code, such as "this is the constructor" or "this loop deletes the selected elements".

[F00dTube]

Of course good code explains itself. I think that it just reaps a lot of benefits later if you just tell the purpose of a codeblock or maybe a few codeblocks. It just gives a hint of what to look for, how to read the code. It's really not that much effort to put in a few scribbles. Besides that it is very important to give a good short description of how to use a class.

[codingkriggs]

I agree with what you're saying, and I won't hate code (say javadoc in java) that describes what a class and each method does. Where I break conventional wisdom is that I put that type of information in an external document (not an auto-generated one), and I don't describe every method, only the ones that need it. Also, the document is written as both a reference and something that can be comfortably read from start to finish, so there's an intuitive order to it (something reference docs lack).

[codingkriggs]

My method really only applies to a fairly specific scenario (a very small team of people who constantly review their own code). It is not incompatible with your own perfect design method. They could compliment each other if you wanted to use both.

[Aemsere]

I tend to disagree that this is a perfect method. I do understand why you choose to implement the least dependent parts first, because that has natural advantages, but it constricts your freedom a lot during the initial phases. It also seems to me that this style requires much talent and attention.

I tend to see testing first, lazy programming, loose coupling, and "fake it till you make it" as a more generally applyable approach.