Communication - A key to "Coding well?"

There once again seems to be a little wave of interesting posts on a new topic. Steve Yegge had a post on what happens when code gets to big. Then my friend Raganwald picked that up and started to dissect the idea. Steve commented that the goal of most coders should be to keep things small (gross paraphrasing from a much longer post), make the overall code base smaller so that it is more manageable and more maintainable. Raganwald takes that idea and makes it painfully obvious why that somewhat simple directive doesn't make full sense without some understanding of what it means to make the code base smaller - stating:

"These are my thoughts about the relationship between program size and readability. It’s my take on how you can look at one short program and dismiss it as Golf, and look at another and praise it as being succinct and expressive."

Raganwald points out that code size is certainly a factor in how manageable a particular code base is, but that a certain amount of code bloat is both inevitable and needed in some cases (my interpretation on the post). You see what I think he is attempting to point out is that its not all about the size but what the size is communicating, and what things went into getting the code base to a given point.

Programmers are people

We all have ways of talking to one another and we speak a similar language here in the USA but not all of us understand one another. There are some local inflections and dialects that can make modern English hard to understand just as if people were speaking two different languages. The same is true of coding even if you happen to be coding using the exact same tool or language. Even if all the programmers involved in a given code base are each coding well it can still be hard for them to understand one another's code. In the end we are all working in a community of programmers (unless we are self employed or working for the man) and we have to understand each other, but is the code enough to garner this understanding between programmers in this case? In my opinion if you were asking Steve Yegge he might say it should be... and Raganwald would likely answer probably not.

Dialects - what is a standard to you may be silly to someone else

So to throw a nail into this idea that even in one programming language you can have different dialects or ways of doing work Max Kanat-Alexander says the following about the Bugzilla code base:

* There are many ways to do the same thing in Perl. It's even the motto: "There's More Than One Way To Do It." However, this means that each reviewer must enforce very strict code guidelines on each coder, or must learn each coder's coding style. In the interest of consistency, we usually pick the former. This takes more reviewer time. It's also frustrating for contributors who are used to writing in a particular fashion.

* More ways to write the same thing means there are many more bad ways to write code in Perl than there are in other languages. In any language it's possible to do stupid things and not realize it. In Perl it's easy. Or even when the code does what you mean it to, just because it works doesn't mean it's good. My experience is that Perl encourages people to write code that "just works," but might not be architected appropriately. Once again, this is possible in any language, but I think Perl makes it easier than other languages to write bad code.

* It's very easy to make Perl code hard to read. It uses strange variables like $_. It relies heavily on complex regular expressions. I don't think anybody would argue that Perl encourages readability.

Raganwald, using design patters as a way to illustrate, makes much the same point. Design patterns are one more way in which programmers can attempt to communicate to other programmers their intention without having to sit next to them and explain it verbatim. Gecko on programming.reddit.com (shamelessly copied from Raganwald, because I don't yet frequent reddit) makes a similar point as an assignment anecdote to his life as a college TA.

So Whats the point

The point is that coding small is good provided that people will understand the smaller code. Code bloat is fine for the same reason but might hurt maintainability which is a different measure, and one should always know how they are being measured. Making code smaller for the sake of being smaller is not a good way of looking at it in my mind. Making the code base smaller when everyone understands how you are making it smaller is a different story.

No matter what you have to make sure that, at the very least, the programmers you are working with are speaking with a common dialect. In my mind not having a common dialect is what leads to a large code base and one that is unmaintainable - and is a problem in the end that can not be solved by simply making the code smaller and more concise as Steve suggests. The problem is also not one that can be solved by introducing Design Patterns although it can certainly help you to get to maintainable code base by virtue of having people understanding what you are saying because they understand your dialect. The problem is unfortunately a people problem and is still unsolved in programming, "how do I make people understand what my code is doing above and beyond what the code 'says' - because it doesn't align with my personal dialect?"

(as an aside I think that the last sentence is what leads to that programmer syndrome that makes all programmers think that another programmers code is pure unadulterated poo.)