Tuesday 4 October 2011

The aesthetics of your code

For better or for worse I'm someone that can spend awful amounts of time pondering on things that many (if not most) would consider irrelevant. Many of those "wasted?" brain cycles are related to programming issues that I still consider important like:

  • Initialize in the constructor or inline?

  • Should this go to a separate class? (how strictly to adhere to the Single Responsability Principle is a constant source of doubt for me)

  • Add another parameter or create a separate method (think and rethink semantics...)

  • This method should go here or there?



So when finding just by chance the excellent reflection of a StackOverflow folk on the Aesthetics of Programming and its intrinsic individual nature I could not resist to copy-paste it here:
Original source

Look at the things that are important: your project, your code, your job, your personal life. None of them are going to have their success rest on whether or not you use the "this" keyword to qualify access to fields. The this keyword will not help you ship on time. It's not going to reduce bugs, it's not going to have any appreciable effect on code quality or maintainability. It's not going to get you a raise, or allow you to spend less time at the office.

It's really just a style issue. If you like "this", then use it. If you don't, then don't. If you need it to get correct semantics then use it. The truth is, every programmer has his own unique programing style. That style reflects that particular programmer's notions of what the "most aesthetically pleasing code" should look like. By definition, any other programmer who reads your code is going to have a different programing style. That means there is always going to be something you did that the other guy doesn't like, or would have done differently. At some point some guy is going to read your code and grumble about something.

I wouldn't fret over it. I would just make sure the code is as aesthetically pleasing as possible according to your own tastes. If you ask 10 programmers how to format code, you are going to get about 15 different opinions. A better thing to focus on is how the code is factored. Are things abstracted right? Did I pick meaningful names for things? Is there a lot of code duplication? Are there ways I can simplify stuff? Getting those things right, I think, will have the greatest positive impact on your project, your code, your job, and your life. Coincidentally, it will probably also cause the other guy to grumble the least. If your code works, is easy to read, and is well factored, the other guy isn't going to be scrutinizing how you initialize fields. He's just going to use your code, marvel at it's greatness, and then move on to something else.


My 2 cents with respect to the question that sparked such a nice text is that I always use "this". On one side it seems more clear to me, on the other hand, in some brilliant languages like Python or JavaScript(well, the mechanism and semantics are quite different from C# and Java and it's not something optional, you could not do withou it) you have to use it, so what is good in JavaScript is good in the rest of the Coding world :-)

By the way, do not miss this impressive ellaboration by the same author on how to get some sort of Class Loader equivalent in C#

No comments:

Post a Comment