220

Sometimes, the best way to know, is to come back to code you wrote six months ago and try and understand what it was written to do. If you understand it quickly - it's readable.


195

This is a "standards smell" to me. Whenever I see coding standards with specific limits in them, I worry. You almost always run into a case where a method needs to be bigger than the standard allows (whether it's line length/count, number of variables, number of exit points, etc). Standards should be more like guidelines, and allow sufficient leeway for ...


138

The only real solution to avoid code rot is to code well! How to code well is another question. It's hard enough even if you're an excellent programmer working alone. In a heterogeneous team, it becomes much harder still. In outsourced (sub)projects... just pray. The usual good practices may help: Keep it simple. Keep it simple. This applies especially ...


118

You cross the line when You have measured that your code is too slow for its intended use. You have tried alternative improvements that don't require mucking up the code. Here's a real-world example: an experimental system I am running was producing data too slowly, taking over 9 hours per run and using only 40% of CPU. Rather than mess up the code too ...


115

Where? On a home page of a Google-scale website, it is not acceptable. Keep the things as quick as possible. In a part of an application which is used by one person once a year, it is perfectly acceptable to sacrifice performance in order to gain code readability. In general, what are the non-functional requirements for the part of the code you're working ...


111

If you felt compelled to expand a one liner like a = F(G1(H1(b1), H2(b2)), G2(c1)); I wouldn't blame you. That's not only hard to read, it's hard to debug. Why? It's dense Some debuggers will only highlight the whole thing at once It's free of descriptive names If you expand it with intermediate results you get var result_h1 = H1(b1); var result_h2 ...


95

Yes. Generally two smaller less complex applications are much easier to maintain than a single large one. However, you get a new type of bug when the applications all work together to achieve a goal. In order to get them to work together they have to exchange messages and this orchestration can go wrong in various ways, even though every application might ...


94

There are many aspects to maintainability, but IMO the most important are loose coupling and high cohesion. Essentially, when you're working with good code, you're able to make small changes here and there without having to keep the whole codebase in your head. With bad code, you would have to take more things into account: fix here, and it breaks elsewhere. ...


94

It is: maintainable if you can maintain it. easily maintainable if someone else can maintain it without asking you for help readable if someone else, on reading it, correctly understands the design, layout and intent The real test for 1. is (as Alex in Paris and quant_dev say) that you can pick it back up after a few months doing something else. The test ...


88

... when arguing with one of my collegues, who is going to the point of declaring constants like: private const char SemiColon = ';'; private const char Space = ' '; private const int NumberTen = 10; The argument you need to be making with your colleague isn't about naming a literal space as Space but his poor choice of name for his constants. Let's say ...


82

It is usually a good idea to split stuff into little methods. But the important thing is to split things where it make sense. If it doesn't make sense to split, then don't split. This is often the case for some procedures or GUI code. Steve McConnell stated in Code Complete that you aren't always more productive when using short methods. If you split when ...


67

Duplicated code : Copy Paste is most probably the single most expensive operation when it comes to maintenance costs of programs. Why bother move this code to a common component, i'll just copy it over and be done with it Yes... the programmer probably saved an hour of work or so doing things this way. However later comes a bug and... yes of course it ...


62

Maintainability isn't a binary property, either being maintainable or not. It's a continuum. Roughly speaking, maintainability is inversely proportional to the amount of time it takes a developer to make a change and the risk that change will break something. Improving readability, coupling, or consistency all contribute to maintainability because it won'...


57

It's a false dichotomy. You can make code fast and easy to maintain. The way you do it is write it clean, especially with as simple a data structure as possible. Then you find out where the time drains are (by running it, after you've written it, not before), and fix them one by one. (Here's an example.) Added: We always hear about tradeoffs, right, such ...


57

That reminds me this code: if ( ... ) try { .. } catch (Exception e) { .. } else { ... } Every time you are combining two types of blocks, forgetting braces and not increasing indentation, you are creating code very difficult to understand and maintain.


55

Unit tests are your friend. Implementing them forces low coupling. It also means that the "hacky" parts of the program can easily be identified and refactored. It also means that any changes can be tested quickly to ensure they don't break existing functionality. This should encourage your developers to modify existing methods rather than duplicating code ...


55

Perhaps it is because I learnt my trade (way back when) using the Jackson Entity Structure Diagram method, but I subscribe to the view that the only correct unbraced term after an if or an else is a subsequent if (ie allowing an else if ladder) Anything else (no pun intended) leaves potential for misunderstanding and/or maintenance issues. That is the ...


52

While code which breaks the rules in the other answers is certainly worse to maintain, all code is hard to maintain, therefore the less of it you have the better. Defects correlate strongly with amount of code, so the more code you have the more bugs you have. Once code get over a certain size you can't keep your whole design in your head anymore and things ...


51

Does splitting a potentially monolithic application into several smaller ones help prevent bugs Things are seldom that simple in reality. Splitting up does definitely not help to prevent those bugs in the first place. It can sometimes help to find bugs faster. An application which consists of small, isolated components may allow more individual (kind of "...


50

On the other hand, the more processing you put on a line, the more logic you get on one page, which enhances readability. I utterly disagree with this. Just looking at your two code examples calls this out as incorrect: var a = F(G1(H1(b1), H2(b2)), G2(c1)); is heard to read. "Readability" does not mean information density; it means "easy to read, ...


40

Everybody here is quick to mention code rot, and I completely understand and agree with this, but it still misses the bigger picture and the bigger issue at hand here. Code rot doesn't just happen. Further, unit tests are mentioned which are good, but they don't really address the problem. One can have good unit test coverage and relatively bug free code, ...


40

The issue I have seen when maintaining code that makes use of flags is that the number of states grows quickly, and there are almost always unhandled states. One example from my own experience: I was working on some code that had these three flags bool capturing, processing, sending; These three created eight states (actually, there were two other flags as ...


40

I prefer 2, but I might go for a small adjustment to it: obj.NeedsChange = ( obj.Performance <= LOW_PERFORMANCE ); To me the parentheses makes the line easier to parse and makes it clear at a glance that you are assigning the result of a comparison, and not performing a double assignment. I'm not sure why that is (as off-hand I can't think of a language ...


38

I think such views are usually reactions to attempts at premature (micro-)optimization, which is still prevalent, and usually does way more harm than good. When one tries to counter such views, it is easy to fall into - or at least look like - the other extreme. It is nevertheless true that with the enormous development of hardware resources in recent ...


38

Coming at your question from the side of a developer who works on high-performance code, there are several things to consider in design. Do not prematurely pessimize. When you have the choice between two designs that are equal in complexity, choose the one that has the best performance characteristics. One of the famous C++ examples is the prevalence of ...


38

Here's an example when flags are useful. I have a piece of code which generates passwords (using a cryptographically secure pseudorandom number generator). The caller of the method chooses whether or not the password should contain capital letters, small letters, digits, basic symbols, extended symbols, Greek symbols, Cyrillic ones and unicode. With flags, ...


38

I'll have to disagree with the majority on this one. Splitting up an application into two separate ones does not in itself make the code any easier to maintain or reason about. Separating code into two executables just changes the physical structure of the code, but that's not what is important. What decides how complex an application is, is how tightly ...


36

Usually, no. Changing the code can cause unforeseen knock-on issues elsewhere in the system (which can sometimes go unnoticed until much later in a project if you don't have solid unit and smoke tests in place). I usually go by "if it ain't broke, don't fix it" mentality. The exception to this rule is if you're implementing a new feature that touches this ...


32

You didn't complain about it being unmaintainable, just not to your liking. If it's a deliberate style choice, it may just be a case of irreconcilable creative differences, and you should adjust your style to fit, or find somewhere that fits your preferred style. People can and do write modular, efficient, well-abstracted, relatively bug-free code in a ...


Only top voted, non community-wiki answers of a minimum length are eligible