A quality what I would like to develop is to write more concise code. With writing more concise, at least in my opinion, the opportunity to add bugs to the code is smaller. It is easier to read the code for other.

My question is if it is something that just comes with experience or is it something you can do explicitly for developing that quality?

  • 6
    Plot the tendency and see when you cross the x-axis...
    – user1249
    Mar 27, 2012 at 9:52
  • 1
    Mandatory pointer to macros, macros, macros: paulgraham.com/avg.html
    – deprecated
    Mar 27, 2012 at 9:55
  • You can generate very terse, readable code by adopting the pointless programming style. Pointless programming is programming only by applying functions. You can recognize it by it's extensive use of higher-order functions like map, filter, concat, fold/reduce/inject/[insert other names for a list catamorphism] etc. Mar 27, 2012 at 10:04
  • 2
    -1: This seems like self-congratulations in disguise.
    – Jim G.
    Mar 27, 2012 at 10:20
  • I haven't yet seen readable point free code. not in any significant library. Mar 27, 2012 at 17:51

8 Answers 8


I would say that on the whole it is something that comes with time and experience, but you may find that if you do some work with more terse languages you bring that quality back to your regular working languages.

Certainly after a year or two working with Ruby I found my C# got a lot tauter. I think if I was to understand functional programming better ( an ongoing ambition ) I would probably take more from that.

Also there are some guidelines that can help- for example if you write the same two lines more than once split them into their own method. That's a simple guideline but quickly cuts down on lines of code and cut and paste programming, which most of us are guilty of from time to time.

If you understand inheritance you can often save on repeating the same code in different places by giving common functionality to parent classes. This is obvious in principle but something people often miss in practice.

There can be a difference between writing less code and having less code in your application- sometimes you can use code generation to avoid having to repeat yourself so you only write a few lines of code but those then generate a whole lot of other code for you- that can give you a lot of leverage. Look at what a tool like Rails or Entity Framework does in this respect to grasp how useful it can be. Be clear about the need for it though and think twice, three times and then four times about rolling your own code generation- that can land you in YAGNI hell.

Understand your language, your API and your tools. Again this seems obvious but over the years I have written so much code that I later realised was reproducing functionality I could have just inherited from the API or used a language feature to simplify that I have come to realise that a few hours of reading up on the documentation for the API I am working with will save me many hours of coding or debugging later on. Similarly, most platforms you work with have a grain - learn to work in the way they expect and your life will be a lot easier. Spend some time finding the direction of least resistance for the platform you are working with and you will get things done a lot better.

If you are wondering whether there is a better way to do something, there probably is and it is always worth finding out how to do things better.

  • Yes, in my opinion, the only reason for private one-line functions is the DRY-principle
    – user1041
    Oct 4, 2010 at 11:25
  • Since I have had more of those functions the number of lines of code in my classes has come down noticeably and it looks a lot neater and clearer.
    – glenatron
    Oct 4, 2010 at 11:26
  • Sounds like a bit of contradiction, more functions but less lines, but maybe I can see the same trend in my code too.. I have to think about that....
    – user1041
    Oct 4, 2010 at 11:31
  • Do you have any more of these guidelines that could be followed? Sounds as though they could be useful to a young dev such as myself. Mar 27, 2012 at 6:53
  • @stuartmclark - I've added a few more, though I suspect there isn't too much there that you wouldn't have heard elsewhere.
    – glenatron
    Mar 27, 2012 at 10:05

One great way to write less code is to try to avoid re-inventing the wheel, and use existing software components when available.

One common answer I get when I ask why people did their own ORM, or their own logging engine, or their own UI components, or their own everything:

But our is better

I believe this statement is correct most of the case, but the negative impact on the ROI is very high in most case. You mom does the best dishes right? But you can't ask you mom to come home and prepare them everyday.

That's why I do think that developers should get interest in financial impact of their choices. Some of them are:

  • Extra work required to build the component
  • Extra work for new comers to learn it
  • Huge extra work to maintain it

I like to think that those component vendors are your extended team working for you for a tiny fraction of what you would have paid to build, maintain and improve it yourself.

It's better for the whole company to maximum ROI rather than working on maximizing our ego satisfaction ;) The more money your company get, the more likely your work conditions and salary will increase.

  • 1
    I'm guilty of that too, a few years ago I wrote my own filepath class could convert filepath between Win, Unix and Apples format. We only used windows. Maybe that is a rule too, never make things future-proof
    – user1041
    Oct 4, 2010 at 11:35
  • Sometimes it's due to your lack of knowledge of a given framework. I did write my own path class too when I started to work with .NET, then I discovered the System.IO.Path class few days after :-)
    – user2567
    Oct 4, 2010 at 11:37
  • I preferred my Mom's spaghetti, but the stuff in the jar was good enough. This really boils down to those in charge of requirements. If they don't settle for the 85% solution, you have no choice.
    – JeffO
    Oct 4, 2010 at 12:56
  • My mom does the spaghetti lot better that yours.
    – user2567
    Oct 4, 2010 at 13:00
  • 1
    +the internets for "avoid re-inventing the wheel". One of the most crucial skills I've developed is being able to identify problems that somebody has probably already solved. Not only does it almost always give me a better solution than I'd have produced on my own by handling a bunch of fringe cases I probably would have overlooked, it frees me up to work on the problems I'm actually getting paid to solve.
    – BlairHippo
    Oct 4, 2010 at 14:10

In my opinion, writing less code can be done in several ways:

  • You Ain't Gonna Need It. Don't code something you don't need yet. Code only the requirements state so. This way, we will reduce the code needed to write.

  • Don't Repeat Yourself. I believe using CMS, framework or the third party library is one way to applying DRY principle.

  • Abstraction. And last but not least, abstraction programming can reduce the code very much too. By abstracting the code the chance to reuse the code will go higher because it reduces duplicacity.


Beyond the understanding of a programming language, I think one's understanding of a problem and coming up with a good solution has a lot to do with it. There are many solutions to most problems, not all of them are optimal. You can drive from city A to city B through different roads - one could take two hours, the other could take double. It's the same idea in programming. You may know a language very well, but you may come up with a solution that takes, say, two pages of code, while somebody else will figure out a solution that can be implemented in a quarter of half the code size. I've seen this a lot over the years.

Make sure you have a good understanding of the problem. Analyze it, come up with solution(s), weigh the pros and cons (of course "solutions with an 's'" will vary greatly from problem to problem - just generally speaking here.) Then there's implementation of the chosen solution, which is where your understanding of the language (and framework, if that applies) will come into play.

  • How much time do you spend preparing the solution versus programming the solution?
    – user1041
    Oct 4, 2010 at 11:39
  • It varies depending on the problem, of course. I'm not talking days here. Spending a bit of time thinking before coding usually pays off. It's not really about the time spent doing either as it is coming up with a good - and ideally maintainable in the long run - solution. I can produce crappy code for crappy solutions alright - anyone can do that. Oct 4, 2010 at 13:10

The entire art of programming can be said to come down to just this.

You can study languages that have a traditional emphasis on clarity and conciseness (e.g. Haskell, Scheme, Python), or even terser paradigms like Factor and other concatenative languages, but ultimately, everything you could choose to study should ultimately contribute to helping you write shorter, less redundant code.


Like all other afflictions, if you don't admit to having a problem, you're not going to look for a solution. Experience starts to be a factor when you've learned what less code looks like. When you revisit your code, it is a great time to determine if you can reuse code or refactor to less code. Microsoft was able to improve printing speed with Windows 2000 by NOT spooling it twice (quote from Microsoft employee at one of their free demos).

  • So I should revisit my code and refactor it for getting a handle on how write less code or as Piet says, terser code?
    – user1041
    Oct 4, 2010 at 13:29
  • 2
    @Gorgen - you could if you have time or just look at any code you wrote an hour ago. Sometimes spotting an example on SO may prompt you to go back and make some changes in your own code.
    – JeffO
    Oct 4, 2010 at 13:56
  1. Go back yo your older long winded code,
  2. put it under version control,
  3. write some tests for it to have a reasonable hope not be introducing new bugs,
  4. rewrite.

Repeat ad libitum. And welcome to hell.


Test Driven development might help. Using this, you write only the minimum code required to pass that test.

  • In that context, minimum is meant in terms of features, not length.
    – deprecated
    Mar 27, 2012 at 9:54