Ars has an interesting article up on minimizing code:
Ankit works in J2SE (core java). During code reviews, he's frequently asked to reduce his lines of code (LOC). "It's not about removing redundant code," he writes. To his colleagues, "it's about following a style." Style over substance. Ankit says the readability of his code is suffering due to the dogmatic demands of his code reviewers. So how to find the right balance of brevity and readability?
Erik Dietrich writes:
I agree with your code reviewers, but with an asterisk. Each statement that you write in your code is a technical liability—it's a potential failure point. If you write a method with 10 statements and your coworker writes one that achieves the same functionality with 5 statements, his is likely to be 'better' as measured by likelihood of issues (there are twice as many places your code can be wrong, overly complex, or problematic).
I currently work as a senior applications developer and project business analyst for a major company and never has the line count of my development been a center of interest. However, I believe that the more condensed a code can be, the better, BUT not at the cost of being able to quickly analyze and correct (or add on to) it. To me, when you are in charge of a business critical application that MUST have a vast level of scalability and be capable of on the fly alterations in a non-stop changing environment, concise, easy to read code is one of the most important elements in development.
Click here to read the whole thing.
What are your guys thoughts on the topic?