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