Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
6  
Plot the tendency and see when you cross the x-axis... –  user1249 Mar 27 '12 at 9:52
1  
Mandatory pointer to macros, macros, macros: paulgraham.com/avg.html –  vemv Mar 27 '12 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. –  dan_waterworth Mar 27 '12 at 10:04
2  
-1: This seems like self-congratulations in disguise. –  Jim G. Mar 27 '12 at 10:20
    
I haven't yet seen readable point free code. not in any significant library. –  Simon Mar 27 '12 at 17:51
show 1 more comment

closed as not a real question by Jim G., Jarrod Roberson, ChrisF Mar 27 '12 at 12:25

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

8 Answers

up vote 10 down vote accepted

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.

share|improve this answer
    
Yes, in my opinion, the only reason for private one-line functions is the DRY-principle –  user1041 Oct 4 '10 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 '10 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 '10 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. –  stuartmclark Mar 27 '12 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 '12 at 10:05
add comment

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.

share|improve this answer
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 '10 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 '10 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 '10 at 12:56
    
My mom does the spaghetti lot better that yours. –  user2567 Oct 4 '10 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 '10 at 14:10
show 1 more comment

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.

share|improve this answer
add comment

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.

share|improve this answer
    
How much time do you spend preparing the solution versus programming the solution? –  user1041 Oct 4 '10 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. –  MetalMikester Oct 4 '10 at 13:10
add comment

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.

share|improve this answer
add comment

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).

share|improve this answer
    
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 '10 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 '10 at 13:56
add comment
  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.

share|improve this answer
add comment

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

share|improve this answer
    
In that context, minimum is meant in terms of features, not length. –  vemv Mar 27 '12 at 9:54
add comment