Stylistic Intuition - Or not!

A fair friend of mine Raganwald wrote a post on the word "intuitive" stating that at least as it applies to programming languages it just isn't (i.e. it doesn't apply). A similar topic came up at work @ Big Co. in the last week or two in the form of something that company has not had to date... a coding style guide and a list of coder guidelines for how common tasks are performed in code at Big Co.

Perception is Reality

Intuitive means different things to different people. Something that is intuitive is really all about how the person looking at a particular item sees that item. As raganwald put it:

"And this is why it [the word intuitive] is not a very helpful word. Like good design, it means different things to different people."

it seems that this point about it meaning different things to different people is where Big Co. programmers are currently caught up. There are a number of people that have stated that the idea of having a coding 'guide' as well as a best practices guide is just a waste of time. Some have also said that the time spent on this endeavor and the time that may be spent on 'enforcing' a standard are wasted. Specifically that Big Co. programmers should be spending their time working at making things simpler or bringing about more simplicity in the code base. While I agree with the idea that Big Co. programmers and architects should be attempting to make the code simpler I disagree that setting a standard and having guidelines is wasted effort - for the "intuitive" reasons spelled out in raganwald's post. Some other things do come to mind that I think make the effort of value as well.

Memory - Value in commonality

Style guides for source code and guidelines for common programming boilerplate tasks do have value. Specifically they have the value of allowing programmers to "study" what the Big Co. code base looks like. This is important in the same way that updating sections of the code base is, its all about peeling the onion. Everyone has the ability to hold a limited number of things in their head when they are performing a task. Studies have shown that in general the number of things a person can hold in their active memory is about 7 +- 2 items. If all the code @ Big Co. follows a similar guide, I can reduce the number of interpretations I have to make between what my 'intuitive' code structure might be, or the way I may have learned it and over time train myself to expect things in a certain way no matter what type of code I look at when working @ Big Co. Once the 'learning' has occurred it is no longer one of the things I have to hold in active memory when performing a task. The learning has made code style and guidelines something that is automatic and basic ala. training someone to do a repetitive job well allowing room in active memory for other items, like classes related to what I am coding now or refactoring currently.

Programmer Ramp up

The style guides and other boilerplate guides also have value for new hires. New programmers starting at any new job almost always ask for any documentation they can get as well as for access to the source code. The first I assume to be an effort to see how "mature" the company is while garnering information. The latter I see as a way of investigating to see if the code is 'intuitive' to them. If you were to give the new programmer, both the code and the guide - they can level set their expectations ahead of time and possibly get started on things faster then that may have otherwise. The guides and guidelines can provide a needed context that a new programmer @ Big Co. might not get nor see if every new class file they open has a different look and feel. Couldn't all the programmers in the organization be faster if they knew in advance what to expect rather then letting each new source file be a style surprise? It should also be noted that there is something to be said here about not giving new hires immediate 'write/commit' access to the source tree but that is a post for a different time.

Simplicity

Style guides drive simplicity for everyone as well. If there is a common set of guides most IDE's and a good number of text editors these days will allow for configuration. It should be more then reasonable to expect that 'configs' for the commonly used tools in the organization (and even some of the one offs) are available to make the formatting easy. Even if you the singular programmer want to have a different or DO HAVE a different way that you need to look at the source code, there is a step by which you can have your environment of choice put the file back into the 'accepted' guide/standard for the organization. In many respects I consider it more lazy to NOT follow some standard then TO follow one. You could even consider it something I consider a service to my fellow programmer.

I think in the end - a weeks worth of fighting about some things I think is worth it in the end. If I save Big Co. developers 5 minutes of time overall / day it could add up to a significant amount of time saved over time. There is always a point of diminishing returns, but I don't think that this topic is one of them.