I’m not sure as to whom to attribute the following statistic, but i believe it was something along the lines of this; Code is read vs. written on at a 10:1 ratio, meaning that the is far more reviewing of any specific codebase than there is writing to said code. Furthermore, the majority of software positions involve maintaining and modifying existing code as opposed to creation of new code from the ground up.
To what does all of this allude? The importance of writing clean code. Knowing full well that other developers are going to have to read, understand and most likely modify your code in question at some point(s) in the future. This is where our responsibility as software professionals (even in the case of hobbyists) comes into play.
Several languages have tried to address this problem by intrinsic design decisions. Most notably among those in recent times are Java and Python. Java does so by its explicitness by design, and Python by its forced formatted a la the whitespace requirement. Both are effective in what they do, however there are still a multitude of ways in which both can be written in a harder to read format. Obviously choice of variable, function, class and object reference names is a very large point of readability (or not) which really cannot be enforced by a language specification. Let us take a look at this very issue and while we’re at it, i’ll be clear that this is not a Python vs. Java issue discussion.
All too easily so many coders (I know this from having had to look at, understanding and refactor their code) overlook one of the best sources for building readable code, and that is their naming convention. There have been several best practices and coding style specifications documents produced that one might think me as flogging a dead horse, but I assure you this is not the case.
In the following examples we see a variation of languages and how we might commonly see the same variable name referenced (and initialised as it were):
Smalltalk:
num_of_doors = 4 ;
Python:
numberOfDoors = 4 OR numDoors = 4 OR number_of_doors = 4
Ruby:
numberOfDoors = 4; OR numDoors = 4; OR number_of_doors = 4;
Java, C#:
int numberOfDoors = 4; OR int numDoors = 4; OR int number_of_doors = 4;
Lisp:
number-of-doors := 4;
C, C++:
int intNumDrs = 4; OR int num_drs = 4; OR int int_drs = 4;
Perl:
my $vzoiuwriozufsd = 0x04;
The point here is that there are many varied ways in which the same variable can be referenced. I am of the opinion that much along the lines of Guido van Rossum of Python (and to a lesser extent ABC) fame, that there really should be one and only one obvious way to do it. This isn’t to say that I think everyone should code in the same language, and speak the same tongue, etc. What it does mean though, is that to be understood by others (and sometimes by ourselves), we need consistency, and unless we have a set of strict guidelines set out for us as software engineers, developers, etc., we might as well code in our own made up dialects.
I am of the opinion that a proper interpreter, compiler, virtual machine, etc., should be more than capable of quickly turning long variable, class, function and method names into concise tokens with small internal footprints. So much to the point that there is no excuse for not being verbose. At one point in time, every single byte of allocated memory for names of the aforementioned items was a crucial issue which required extreme concise naming conventions to be followed. Those times are gone in this day and age, allowing us to be clearer and more expressive.
I can see using single letter counter variable names, but never could I imagine naming a class, method or function in such a sparse manner. I like to think that clean code reads somewhat like a choose your own adventure book, were it to have a greater variety of options available. Functional or Object Oriented is immaterial here, as cleanly written code isn’t tied to a specific construct or paradigm. I think most of the following rules are applicable to pretty much every language out there. Emphasis below pertains to items that I feel are not language specific guidelines.
As can be seen, most of the above are applicable to languages other than Python. I find myself at my current place of employment having to deal with the problems for which this list addresses. Much of what I’m doing is updating a legacy code base that is literally plagued with dozens of individual programs and modules that are blatant attacks on decent code. They (collectively) single-handedly break most of the above guidelines.
First off it is almost entirely written in perl, which instantly shoots down the Readability counts factor (and no, it wasn’t done with the strict pragma, and yes it uses a bunch of requires and plenty of global variables).
Secondly, errors don’t pass silently because there is no built-in exception handling in perl. Evals of code blocks does not equate to a proper exception system, nor does an add-in module. Exceptions are something which need to be a core part of the design of the language, and perl falls far short of the bottom of the heap on this issue alone.
Thirdly, when one is expected to maintain code in an environment wherein the expectation is to follow the existing coding schema as it were, with global variables, no exception handling, etc., it truly becomes a daunting task because one must force his/herself to think ‘wrong’. The logical and/or proper solution that is naturally though of as a solution would only lead to reprimand, simply because trying to think in such a manner will produce mistakes, primarily because trained seasoned professionals don’t think in the same manner as the less experienced coder(s) responsible for the legacy code int eh first place.
Finally, (I’ll leave it to three to be nice to those few perl hackers who’ve read this far), after ten plus years of coding in perl, I’ve come to learn that the TIMTOWDI (There Is More Than One Way to Do It) mantra of perl is one of the biggest problems that arise from the language. It is this careless and dare I say reckless mindset which has led to so many atrocities in the professional coding world.
My point is simple enough to follow. Write readable code, as it is a defining factor as to how far you’ve matured in the field of software development. It doesn’t necessarily mean you are even that good at what you do, but what it does do is show how you understand a rudimentary problem that so many others have failed to realise. Readability Counts, and without it, we are truly lost.
No comments:
Post a Comment