Are you a hacker or a craftsman? Clean code and SOLID design principles: surely these are concepts that any developer writing code in an object-oriented language must be familiar with in this day and age? Well, it seems not. It seems like a lot of developers are stuck in the 1980s. I see lots of code that demonstrates a complete lack of understanding of either of these principles. Let me start with an example, one particular method decompiled from a recent product release, contemporary code that doesn’t have the excuse of any historical baggage:
1:privatevoid ParserThread(object clientsocket)
2: {3:bool flag = true;
4: Socket socket = (Socket) clientsocket;5:try
6: {7:while (flag)
8: {9:if (socket.Poll(10, SelectMode.SelectRead) && socket.Available == 0)
10: flag = false;
11:elseif (socket.Available > 0)
12: {13:byte[] numArray = newbyte[socket.Available];
14: socket.Receive(numArray, numArray.Length, SocketFlags.None);15:string @string = Encoding.UTF8.GetString(numArray);
16:char[] chArray1 = newchar[1]
17: {18:'\n'
19: };20:foreach (string str1 in @string.Split(chArray1))
21: {22:char[] chArray2 = newchar[2]
23: {24:'\r',
25:'\n'
26: };27:string str2 = str1.Trim(chArray2);
28:if (str2.Length >= 1)
29: {30:string toret = string.Empty;
31:string str3 = "SRV";
32:string id = "0";
33:string varname = string.Empty;
34:string[] strArray = str2.Split(newchar[1]
35: {36:' '
37: });38:if (Enumerable.Count<string>((IEnumerable<string>) strArray) > 3)
39: {40:string str4 = strArray[0].ToUpper();
41: str3 = strArray[1].ToUpper(); 42: id = strArray[2].ToUpper(); 43: varname = strArray[3].ToUpper();44:if (str4.Contains("GET"))
45:this.asdrv.get(str3, id, varname, ref toret);
46:elseif (str4.Contains("SET"))
47: {48:if (Enumerable.Count<string>((IEnumerable<string>) strArray) > 4)
49: {50:string varvalue = string.Empty;
51:for (int index = 4; index < Enumerable.Count<string>((IEnumerable<string>) strArray); ++index)
52: varvalue = index != 4 ? varvalue + " " + strArray[index] : strArray[4];
53: toret = this.asdrv.set(str3, id, varname, varvalue);
54: }55:else
56: toret = "ERR bad message";
57: }58:else
59: toret = !str4.Contains("NFO") ? "ERR unknown command" : this.nfo_cmd(str3, varname);
60: }61:elseif (Enumerable.Count<string>((IEnumerable<string>) strArray) > 1)
62: {63:string str4 = strArray[0].ToUpper();
64: str3 = strArray[1].ToUpper();65: toret = !str4.Contains("NFO") ? "ERR unknown command" : this.nfo_cmd(str3, "name");
66: }67:else
68: toret = "ERR bad message";
69:byte[] bytes;
70:if (toret != string.Empty)
71: bytes = Encoding.UTF8.GetBytes("OBJ " + str3 + " " + id + " " + varname + " " + toret + "\n");
72:else
73: bytes = Encoding.UTF8.GetBytes("OBJ SRV 0 ERR no datas\n");
74: socket.Send(bytes, bytes.Length, SocketFlags.None); 75: } 76: } 77: } 78: } 79: }80:catch (ThreadAbortException ex)
81: {82: Program.DebugMsg(4, "network:ParserThread : caught abort");
83: socket.Shutdown(SocketShutdown.Both);84: socket.Disconnect(false);
85: }86:catch (SocketException ex)
87: {88: Program.DebugMsg(4, "network:ParserThread : socket lost");
89: }90:catch (Exception ex)
91: {92: Program.DebugMsg(4, "network:ParserThread, unknown exception : " + ex.Message + Environment.NewLine + ex.StackTrace);
93: socket.Shutdown(SocketShutdown.Both); 94: }95:finally
96: { 97: socket.Close(); 98: } 99: }
This code is a great example of something that is neither ‘clean’ nor ‘SOLID’ and it belies procedural thinking. The author of this code is in fact experienced in C, which would explain the procedural bias. Other than that, it is a delightful pot-pourri of poor naming, DRY violations, ‘Arrow Code’ and all manner of other poor practices. My particular favourite is the method of determining the length of an array, which first occurs on line 38. The author has missed the obvious Array.Length property and gone for converting to an IEnumerable, then iterating over that IEnumerable to count the number of entries; then repeating that Frankenstein code several more times throughout the method in a festival of DRY-rot. I’m sure you can find many other ‘broken windows’ in this code.
My point is really this. A lot of people come to object oriented languages having had some degree of experience with procedural languages like C and BASIC. They learn the syntax of the new language, but not the design philosophies. I have met with some difficulty in the past trying to convince developers that they need to up their game. Procedural thinkers can’t see any problems with the way they write code and are quite happy to ignore OO design principles and coding best practices; in some cases they are met with open hostility, being categorised as a waste of time that just gets in the way of writing more code. So this leads me to the question: Does it really matter? So what if developers write so-called ‘bad code’? The program works, the product is shipping. Who cares?
Well I don’t really have a satisfactory answer for that, and that is what’s bothering me. Every fibre of my intellect screams when I read that code, but looking back on my own programming experience, I know that 20 years ago, perhaps even 10 years ago, I might have written code just like that. My programming experience began in about 1977 when I attended a course on BASIC programming. Later on I learned FORTRAN and COBOL, Pascal, C, C++ and had a few excursions into languages such as LISP and Prolog, Perl, VBScript and VB. Professionally, I developed firmware for a whole bunch of microprocessors and microcontrollers in assembler and C and for the last 12 years I have programmed almost exclusively in C#.
I’ve observed some radical shifts in thinking in the developer community over the last decade, but probably the last 5 years in particular. Principles such as ‘Clean Code’, SOLID design principles, DRY, YAGNI, KISS, unit testing and test-driven development, continuous integration and delivery and more. These are things I am either actively doing now or aspire to. So where did I ‘go right’? Why is it that I’m no longer writing code like that in the example above? Does it matter? And if so, how do we get other developers to do likewise? Where does a new developer start, in order to learn to do things right, instead of picking up a pile of 1980s bad habits? Why is it that Basic is still the first language that many new developers are exposed to? Is 1980’s style programming a right of passage that every developer has to undergo?
If you are a new budding developer, or if you’ve been a developer for more than 5 to 10 years, it might be worth taking time to review the industry’s accumulated experience and current best practices. These are some of the resource that I have found helpful.
- Clean Code. Perhaps the biggest service you can ever do yourself is to watch a training video on the subject of Clean Code such as this one from Pluralsight (you can watch it for free if you sign up for the free trial). The Pluralsight course touches on an interesting concept: are you writing code for the computer, or for people? It compares writing a computer program to writing a book. I learned a lot from this course even after 30-odd years of programming experience; I suspect how you answer this question fundamentally affects your outlook and attitudes towards programming.
- SOLID design principles– and another Pluralsight course.
- Coder to Developer – a free training video series from TekPub, covering similar topics to Mike Gunderloy’s classic book of the same name.
- The Joel Test– 12 steps to better code. While this article, published in 2000, is a little dated now, it still contains some really great advice on how to up your game as a developer. In fact, go and read that whole blog!
