Tag Info

Hot answers tagged

163

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


103

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


82

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


79

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


54

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.


52

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

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.


48

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


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


44

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


40

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


38

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


37

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


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.


33

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


32

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


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

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


31

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


29

In the specific case of SQLite, the main tool they've chosen to use in development and maintenance is automated testing. They pride themselves on 100% coverage (branch coverage, not statement coverage) in their test suite. According to them, it's one of the best-tested software products in the world. So they know right away when something they've added or ...


29

Keep your indents few, your names descriptive, and don't be afraid to break a line. Keep your indents few. Often when I find myself in a struggle between indents vs descriptive naming, I take a step back and look at my indention level. If you're indenting further than 3 or 4 levels (2 levels is automatic and unavoidable in many instances. Read: class ...


26

Based on what you describe, you're probably going to want to explore the wonderful world of databases. It sounds like many of the magic numbers you describe - particularly if they are part dependent - are really data, not code. You'll have much better luck, and find it far easier to extend the application in the long run, if you can categorize how the data ...


25

I think the second form is fine, and also more clearly represents what you're trying to do. You say that... I recall reading in code complete that doing things like that is bad for maintainability. This is because you are relying on the language to not evaluate the second part of the if if the first part is false and not all languages do that. It ...


25

The facts: i++ and ++i are equally easy to read. You don't like one because you're not used to it, but there's essentially nothing you can misinterpret it as, so it's no more work to read or write. In at least some cases, the postfix operator will be less efficient. However, in 99.99% cases, it won't matter because (a) it'll be acting on a simple or ...


25

The GPL requires that it be the preferred version for editing. If you normally write in obfuscated code, and make changes directly in it, then that's the source for GPL. If you work on a readable version, and then run it through any sort of obfuscator, the readable version is what the GPL considers the source. "Readability" is subjective and not defined. ...


25

Possible reasons are caching, naming or forcing type Caching (not applicable) You want to avoid the cost of creating an object during the act of comparison. In Java an example would be BigDecimal zero = new BigDecimal ("0.0"); this involves a fairly heavy creation process and is better served using the provided static method: BigDecimal zero = ...


23

In my OSS existence I do a lot of library work aimed at performance, that is deeply tied to the caller's data-structure (i.e. external to the library), with (by design) no mandate over the incoming types. Here, the best way to make this performant is meta-programming, which (since I'm in .NET-land) means IL-emit. That is some ugly, ugly code, but very fast. ...


23

Shorter methods are very much more readable - fewer things to keep in mind to understand them. The most vocal advocates of clean code would probably say that almost all methods should be shorter than 8 lines. And pretty much every developer who's interested in the topic will agree that 70-80 lines of code in a method is too much and it should be broken up.


23

No. C# is giving us more options to write code more succinctly. This can be used or abused. If used properly, it makes the code easier to read. If used improperly it can make the code harder to read. But bad programmers have always had a skill in writing hard to read code. Lets take two examples, both based on examples found on StackOverflow regarding the ...


21

From my understanding, a verbose language is easy to read and understand, while a terse language is concise and neat, but more difficult to read. This is false. Verbose means lots of symbols. Terse means fewer symbols. This has nothing to do with ease of reading or ease of understanding. Some folks find verbose COBOL easy to read, other find it ...



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