posts - 221,  comments - 7542,  trackbacks - 326

I was reading a post by Perci Reyes (spanish link) inspired by a Coding Horror post about understanding code. After reading it and all related links (Joel's thoughts and Peter Hallam's post) I have something to add that it seems nobody thought about...

I agree we all of the authors about the current developer's activities statistics... and maybe it's true that we spend a lot of time trying to understand code. By default, programmers are so narcissist that they need to feel they created something, so they are prone to change anything they don't understand to a more suitable and personal solution, under their point of view. Everybody seems to argue about this narcissism and programmers willing to rewrite instead of understanding but I have some doubts about it being a programmer's problem instead of a code problem...

I mean... is the code too complex to understand it? Maybe it is. I've personally seen thousand of lines of code impossible to read and understand because the chosen architecture, data or business layers, presentation model or even UI layer where poorly and improperly designed, or even not present at all. That adds lot of complexity, but you should agree it's not related to the programmer modifying that code. It's related to the code itself. That code was once written by a developer that thought it was the best solution to the business problem (or maybe it was the best suitable solution possible that could be written with the project, developer and solution constraints present at that time; or maybe related to a lack of experience or knowledge in the side of the developer on how to write that code)

I guess that if a team of peers are developing a solution they do it the best way they can, using known patterns, decoupling code and user interface, and refactoring classes and methods. Following some simple rules you should be unable to find something like a 400 lines method or a class with only one method and 2000 lines of code. And I swear this kind of code exists, I've seen it lot of times.

In that case I would obviously replace and rewrite the smelly code. Not because I prefer it my way, just because it's so poorly designed that it will drive us mad while developing the solution; but most important, it will frustrate working hours of future developers maintaining that code.

So, my point about all that thread of posts was simply to include that developer's are narcissist but they are also able to read understandable code. The problem is introduce by poorly designed software, that actually is pretty common to find anywhere. We need to have in mind that any software we develop will hit production sometime, and it will be supported by a team of developers (maybe not the same team who wrote it) that will need to understand it.

So, my personal advice is (and this is what I actually do when I wrote code in a project) that every developer out there should write the code the best way possible but always making it perfectly readable and understandable. The code must talk by itself, not through the use of code comments, and you should refactor and simplify it until you get something readable and understandable by mere humans. It's not that hard. There are lot of practices to achieve this goal and it will also, under my point of view, make you a better developer; but my favorite statement about this is:

"if you feel the need to add a comment, just refactor your code so it the comment seems superfluous; this way your code will be simpler and easier to understand"

posted on Saturday, December 16, 2006 4:07 AM

Post a new comment about this topic
Title  
Name  
Url

Comments   
Protected by Clearscreen.SharpHIPEnter the code you see: