Less is more, right? Second, less statements means less debugging! If there's a bug in your code, you'd rather check ten statements than a hundred statements.Īnd last, but not least, each statement you write contains a potential bug. Less to read means less for them to understand. First of all, if people read our code, there's simply going to be less to read. If the line count is thousands of lines of code, then the file, and likely the entire project, probably isn't KISS.īefore you go and write me hate mail on why number of statements is a bad measure, let me explain why I think it's actually pretty valid. Still, when I inherit a project, I like to take a look at the line count in files I need to work with. Measuring programming progress by lines of code is like measuring aircraft building progress by weight. Most languages allow nesting statements or putting multiple statements on a single line, so lines of code obviously aren’t going to help much.īill Gates had similar feelings about counting lines: A statement is an action a program takes-for example, declaring and/or assigning a variable, calling methods, looping through a collection, and so on. So how, then, can we write simple code? What I'm going to say now may be a little controversial, but I'm a big fan of counting the number of lines in my code base.Īctually, to be more precise, I count the number of statements in my code. Unless you're in Tenacious D, who just so happened to play the best song in the world, you're not going to write the best code in the world. And that is usually just a small step of a bigger process, so count the different ways you can complete that process, multiply it by the different ways you can get data from a database, and the ways you can write this process probably gets close to an infinite number. ![]() ![]() Now, if we were going to count the ways in which you can write your SQL or LINQ query, you'd soon come to the conclusion that literally hundreds of ways exist to do something as simple as get data from a database. NET) or you may write the query in your code base using ADO.NET or perhaps you're going to write a LINQ query with Entity Framework (or LINQ to SQL, or maybe you're still stuck with Typed Datasets). To fetch data from a database, you may write a stored procedure and call it using ADO.NET or Entity Framework (assuming you use. In general, each programming task can be performed in countless ways. Many programmers just get stuck in a certain train of thought, which isn't necessarily the right train of thought. Programmers often like to be “clever” and make code more complex than it has to be (because, let's be honest, using Reflection to get a properties value is much more fun than just getting the value). Some people just like to show off with complex code. You might understand it (now), but come back in a couple of years (or even months) and look at it again.īut why is so much code not simple? There just aren't a lot of people that possess the skills I just laid out: abstract thinking, knowledge of the domain, and technology. ![]() Actually, if you looked at the code closely you'd probably find it littered with so-called “anti-patterns!” But here's the deal: the same goes for your code. And who wrote that code? Were they beginners, hobbyists, seniors? Perhaps you've seen code from all those people-chances are, they were all complex monsters. Think about it for a second-how much code have you seen that was easy to read, that was simple enough to understand? Probably not a lot. Good programmers write code that humans can understand. In fact, let me present you this quote by Martin Fowler:Īny fool can write code that a computer can understand. It requires knowledge of the code, the framework, and the language you're working with. It requires knowledge of the domain you're working on. Keeping things simple is, ironically, not simple! It requires abstract thinking. ![]() Duh, why would you write complex code? Maybe you even think of yourself as not being a good enough programmer to write complex code! Let me tell you why this is probably not the case. And now you're probably thinking you're already doing that. Simple code is less prone to bugs, and is easier to read and understand for you and the people who'll be working on the code in the future (including yourself). So what should I tell you about KISS? It really just means you have to keep it simple. No matter what your style of coding is, it should follow one rule: Keep It Simple, Stupid! Is it DRY-Don't Repeat Yourself? Or are you more a YAGNI-You Aren't Gonna Need It-person? Do you follow SOLID principles? Or are you really sick and tired of all these abbreviations we have in IT, and just use common sense instead? Let's talk about KISS, or “Keep It Simple, Stupid” as a principle for effective Software Engineering.īut before I go any further, just think a little about your favorite best practice when writing code.
0 Comments
Leave a Reply. |