Tag Info

Hot answers tagged

207

In layman's words: The important thing is not the numbers of lines but the readability of the code. Any fool can write code that a computer can understand. Good programmers write code that humans can understand. (M. Fowler) In the examples you gave, the second one is definitively easier to read. Source code is for people to read. Besides, ...


97

It depends, and your example is not useful in making the decision. While fewer lines of code are not always better (at some point it leads to obfuscation), they usually are, simply because there's fewer things to keep track of when trying to understand the code. In your specific example: If the names of the intermediate values actually convey meaning that ...


65

The best "rule" I've heard is that name lengths should be proportional to the length of the scope of the variable. So an index i is fine if the body of the loop is a few lines long, but I like to use something a little more descriptive if it gets to be longer than 15ish lines.


48

Each variable should have a meaning, and its name is a part of that meaning. And a very important part, since it helps the reader to understand what it is for without digging deeper into algorithm. i, j are obvious to be used as indices, they are short, but very informative. bnt is ugly, close or closeButton are meaningful. So being short or long is not the ...


48

To give a more general answer: In a case like this, you have two programming "best practices" that are opposed to each other: code consistency is important, but so is choosing the best possible method to accomplish your task. There is no one correct answer to this dilemma; it depends on a couple factors: How beneficial is the "correct" way? Sometimes ...


41

Code with as few lines as possible is definitely the best code and every semi-colon you see is basically the developer admitting they weren't clever enough to use advanced constructions like the comma operator or short-circuiting operators to keep the line going as long as possible like you can say `(x++ && false) || y += 2` instead of `x++; y += 2` ...


33

The apparent need for a go-to statement arises from you choosing poor conditional expressions for the loops. You state that you wanted the outer loop to continue as long i < 10 and the innermost one to continue as long as j > 0. But in reality that's not what you wanted, you simply didn't tell the loops the real condition you wanted them to evaluate, ...


32

In this instance, you could refactor the code into a separate routine, and then just return from the inner loop. That would negate the need to break out of the outer loop: bool isBroken() { for (i = 0; i < 10; i++) for (j = 10; j > 0; j--) if (j == i) return true; return false; }


30

Measuring programming progress by lines of code is like measuring aircraft building progress by weight. (Bill Gates) Of course, fewer lines are not always better. But in my experience, fewer lines are often better than more lines in terms of readability and maintainability. There are exceptions, of course, and your example might be one such exception. ...


25

This is clearly wrong. It is the job of the version control system to keep track of changes, and it is the job of diff tools to show what has changed as a result of the merge. There should be a comment in the commit log, and maybe in the code, explaining what was changed and why. However, IMHO, leaving the conflict markers in as comments is the same as ...


20

Staying consistent has little value in my perspective; continuously making improvements is a must. Your colleague's position really impedes innovation. The consistency argument gets you into a situation where you can use, for example, LINQ only if you migrate all code to use LINQ. And well, we don't have time for this, do we? I'd rather have inconsistency ...


19

Here is what Robert C. Martin (the "clean code" guy) would do: http://blog.objectmentor.com/articles/2009/09/11/one-thing-extract-till-you-drop So I guess he would split up your isCreditOk function further like this public int calculateOrderPrice(Set<Item> items) { int orderPrice=0; for(Item item: items){ ...


18

The refactored example is objectively superior because it has less repeated code. Therefore, that implementation is actually simpler, and probably shorter. There is also the argument that the original code in your example is an ad-hoc implementation of traits (or an awkward expression of the strategy pattern), the result being unnecessarily complex code. In ...


15

There's nothing wrong with using a non-owning pointer to someone who points back to you. Just make sure it's not owning.


13

I will use an identifier that describes the variable, irrespective of length. The cases of i,j and k are in themselves so ubiquitous they are self describing, you automatically know they are loop indices. You could also say the same for : foreach loop (Strings s : myString) However, IDE's now provide code completion tools so the only negative side ...


12

In the first version, it is hard to see which parameters are passed to which method. So the second version is clearly better. In other cases however may not be that obvious. The main difference of the second version is that it allows you to name the intermediate values. There may be cases where this name is crucial for understanding the code. If however ...


11

Joel wrote a good article on this Making Wrong Code Look Wrong In short, you want to use Apps Hungarian, not Systems Hungarian notation. Because really, who cares if it's an int, or a long, or whatever, all I care about is the "kind" of value, not it's type.


11

It looks like you're using JavaScript, which changes the paramaters ever so slightly. Unless you have a reason to store those var's, you'd be better off not initalizing them at all. But, you should make the single-statement version as readable as possible, by adding whitespace and a comment. //Do X, Y, Z.... var result = methodOne( methodTwo( ...


10

Like the Pirate Code, the SRP is more of a guideline than a rule, and it's not even a particularly well-worded one. Most developers have accepted the redefinitions of Martin Fowler (in Refactoring) and Robert Martin (in Clean Code), suggesting that a class should only have one reason to change (as opposed to one responsibility). It's a good, solid (excuse ...


10

I tend to think less in "paradigms" and more in terms of using the most appropriate (i.e. - simple, readable and maintainable) tool for the job. I don't believe in sticking rigidly to paradigms because I feel that often results in going out of your way to write code in a certain manner just for the sake of adhereing to the "rules". However it's certainly ...


10

Your second example is more readable (although I would invert if to reduce nesting and rename isCreditOk to isPurchaseAllowed, and possibly moved the latter to Customer). First one hides code intent, exposing implementation, thus while it's clear what code exactly, it's not clear why it does those things.


9

They are not as bad as the misleading identifiers. I don't mind debugging code in which the identifiers are only one letter, but the moment different naming conventions come into the picture it becomes annoying. E.g., if somewhere you see strPersonID, and then somewhere else you see s_EmployeeID, then it's confusing to tell if are these both strings and ...


9

Creating an object only to call some method on it and then discard after the call is generally a bad idea. So, one possible solution is to convert that instance method to a static method. You can also leave it as an instance method but use only one instance of that class throughout the code. The latter can be enforced using the Singleton Pattern, as @AJC ...


9

I'd figure out a new variable name instead of trying to figure out what naming convention to use for a double-number variable That said, if I absolutely HAD to use a double-number in my variable name, and I couldn't rearrange the words/numbers to come up with something reasonable, and absolutely no other name would make sense, I would use an _ between the ...


8

I liked the old way because the capital letter told me that, just like Math.sin(x), ThirdPartyLibraryWrapper.newThingy(x) did the same thing the same way every time. There's no object state to change how the object does what I'm asking it to do. That is the right way to do it, yes. That said, static confers no guarantees of immutability or state ...


8

My rule of thumb is to put each operation on its own line. This is especially helpful when stepping through code with the debugger. I also like assigning the result of an operation to a variable before passing it along so that I can break and examine its contents. so instead of var result = methodOne(methodTwo(a, methodThree(b)), c, d); I would go var ...


8

Is fewer lines of code always better? The short is simply no. The longer one, no, because it depends. How long is the code I want to shorten? If the code doesn't fit the screen, shortening it often makes it more readable How much is done in single line? If it's an access through 10 objects, it's surely good idea to split it to many lines What is better? ...


8

I agree with Kevin Cline. You ought to extract those four lines in a method. It's true that the number of lines of code you save is small, but the process gets much more straightforward, you have less clutter, more testability, and less risk of forgetting one line. The "Don't Repeat Yourself" principle has less to do with saving lines of code (sometimes, ...


8

This is something that you need to take on a case by case basis. I would argue that you should use unfamiliar features of a language if it would improve clarity and make future maintenance easier (both of which your example accomplishes in my opinion). You should never use features just because you want to be clever or because you want to use the feature ...


7

We write code for other humans to read. New technologies are intended to make code easier to read, not harder. There are good and bad ways to use new technologies. If you're trying to write "impressive" code, you're doing it wrong. I suspect it's not just the use of the technologies that is concerning people. If the way you're using LINQ made a huge ...



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