Tag Info

Hot answers tagged

171

Testing code that does lots of things is difficult. Debugging code that does lots of things is difficult. The solution to both of these problems is to write code that doesn't do lots of things. Write each function so that it does one thing and only one thing. This makes them easy to test with a unit test (one doesn't need umpteen dozen unit tests). A ...


116

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.


105

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


102

When used at the start of a block, as first checks made, they act like preconditions, so it's good. When used in the middle of the block, with some code around, they act like hidden traps, so it's bad.


83

The LoC in a method is a completely pointless measure. The important things are separation of concerns and code duplication. A method should only do one thing, and that one thing should be expressed in its name. Other things should be left to other methods. The problems arising from code duplication cannot be overestimated (in other words, they are always ...


80

I could overload the constructor so that order [of the parameters] doesn't matter... But is that a good idea? No. Having different constructor overloads will have the opposite effect of what you are intending. The programmer coming after you expects different overloads to have different behavior, and will ask: "What sort of different behavior is being ...


70

No, long methods are not always bad. In the book Code Complete, it is measured that long methods are sometimes faster and easier to write, and don't lead to maintenance problems. In fact, what is really important is to stay DRY and respect separation of concerns. Sometime, the computation is just long to write, but really won't cause issue in the future. ...


58

Yes, splitting long functions is normal. This is a way of doing things that's encouraged by Robert C. Martin in his book Clean Code. Particularly, you should be choosing very descriptive names for your functions, as a form of self-documenting code.


51

IMHO, this is a very bad idea. Reserved words are reserved for a reason, and doing this does decrease readability. I also entirely agree with your second point. Naming a variable class, even if you could do it, would be just as bad as naming it tmp or a. What kind of class? A class of what? Names should be descriptive.


50

Both. Your first example is certainly more verbose, and arguably more explicit... but it also requires me to scan five lines instead of one. Worse, it deemphasizes its purpose - assigning a value to newGuy.Boss. Your second example may cost me a second if I'm unfamiliar with the null coalescing operator, but there can be no doubt as to its purpose, and if ...


50

All names should be meaningful. If _ was a well known standard at your company or in the wider community, then it would be meaningful as a "name that does not matter". If it's not, I would say it's bad practice. Use a descriptive name for what you refer to, especially since the name might matter in the future.


50

Inner functions are not an anti-pattern, they are a feature. If it doesn't make sense to move the inner functions outside, then by all means, don't. On the other hand, it would be a good idea to move them outside so you can unit test them easier. (I don't know if any framework lets you test inner functions.) When you have a function with 250+ lines, and ...


49

"Fewer lines" isn't always the same thing as "more efficient". I assume you mean "Should a program be made shorter at the expense of readability". Programs must be written for people to read, and only incidentally for machines to execute. -Abelson & Sussman, Structure and Interpretation of Computer Programs In general, I think it's more ...


48

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


46

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


46

I would take a step back here. You're concentrating on the picky details of the code but missing the larger picture. Let's take a look at one of your example loops: int offset = 0; while(true) { Record r = Read(offset); if(r == null) { break; } // do work offset++; } What is the meaning of this code? The meaning is "do some ...


44

Null coalescing operator (??) Personally, I don't see any downsides to using this operator. Consider the following three code samples, from 'easy' to 'complex' new operators. Without magic: bool isNameSet = false; string name; if ( isNameSet ) { Console.WriteLine( name ); } else { Console.WriteLine( "No name set." ); } Ternary operator: bool ...


44

Most of the focus here seems to be around the word always. Yes, absolutes are bad, and software engineering is almost as much art as it is science, and all that... but I'm going to have to say that for the example you gave, the method would be better if it was split up. These are the arguments I'd typically use to justify splitting up your method: ...


39

You could read Donald Knuth's 1974 paper Structured Programming with go to Statements, in which he discusses various uses of the go to that are structurally desirable. They include the equivalent of break and continue statements (many of the uses of go to in there have been developed into more limited constructs). Is your boss the type to call Knuth a bad ...


39

"Simple" is an overused word. "Readable" can profitably be defined as "simple to understand", in which case increasing (this measure of) simplicity by definition increases readability, but I don't think this is what you mean. I've written about this elsewhere, but generally something can be called "simpler" either by being more abstract (in which case fewer ...


39

I'd put the fluent api to it's own "builder" class seperate from the object it is creating. That way, if the client doesn't want to use the fluent api you can still use it manually and it doesn't pollute the domain object (adhering to single responsibility principle). In this case the following would be created: Car which is the domain object CarBuilder ...


35

Always code for the programmer first and the computer second. If there is a performance difference, after the compiler has cast its expert eye over your code, AND you can measure it AND it matters - then you can change it.


34

Purely from a style standpoint, I think these three lines: T current = next; next = fetcher.getNext(); return current; ... are both more obvious and shorter than a try/finally block. Since you're not expecting any exceptions to be thrown, using a try block is just going to confuse people.


34

As people pointed, this improves readability. A person reading process_url() may see more clearly what is the general process to deal with URLs just by reading a few method names. The problem is that other people may think those functions are used by some other piece of the code, and if some of them need to be changed they may choose to preserve those ...


33

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


33

I would say that it's an acceptable practice. This is a rare instance where I would consider the majority to be wrong and in need of updating their knowledge of recent programming ideas. In many languages, particularly ML-based functional languages like Haskell and OCaml, it is extremely common to use _ as an "unused" variable. Even Lua, which doesn't ...


32

Nested loops are fine as long as they describe the correct algorithm. Nested loops have performance considerations (see @Travis-Pesetto's answer), but sometimes it's exactly the correct algorithm, e.g. when you need to access every value in a matrix. Labeling loops in Java allows to prematurely break out of several nested loops when other ways to do this ...


31

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


31

Within Java, there are many tools available to make certain things less verbose, you just have to be aware of them. One that is useful in this case is that of the static import (tutorial page, wikipedia). In this case, import static java.lang.Math.*; class Demo { public static void main (String[] args) { double X = 42.0; double Y = ...



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