Tag Info

Hot answers tagged

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; }


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


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


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


6

No, I don't think a goto is necessary. If you write it like this: bool broken = false; saved_i = 0; for (i = 0; i < 10 && !broken; i++) { broken = false; for (j = 10; j > 0 && !broken; j--) { if (j == i) { broken = true; saved_i = i; } } } Having &&!broken on ...


4

The conventions I use are //non-private variable variableName //private variable _variableName //methods MethodName //parameters parameterName //Properties PropertyName These are standard MS c# conventions. There is a list here. If you want something to help you keep nice clean code following conventions, consider Resharper add-on for Visual Studio


4

I think your intention in making all local variables final is very good practice, but doing so implicitly (i.e. not explicitly with the final keyword) is a bad idea. Rather than worry about readability for yourself, think about future maintainers of your code: will anyone reasonably expect that reassigning a field without the final keyword will fail to ...


3

Promises provide a clean separation of concerns between asynchronous behavior and the interface so asynchronous functions can be called without callbacks, and callback interaction can be done on the generic promise interface. There is multiple implementations of "promises": node-promise promised-io or the most popular Q For example you can ...


3

The short answer is "it depends". I advocate to choose regarding legibility and understandability of your code. The goto way might be more legible than tweaking the condition, or vice versa. You might also take into account least surprise principle, guideline used in the shop/project and consistency of the code base. For instance, goto to leave switch or ...


3

Quick googling shows that some research has been done. For instance, this paper shows that there's a value of cyclomatic complexity of code that minimizes bug rate: Probably deep nesting may be fine as long as it does not branch at every point. That is, a having many nested conditions on top, as in your example, is probably fine, since it's essentially ...


3

There is no better choice in general. Code readability and system performance are two valid goals, and if they are at odds, you must know about the strengths of those two forces in your particular situation before deciding. To say, "when readability and performance are at odds, always choose performance (or readibility)" would be a terrible ...


2

The point of an assertion is to indicate that the parameters which are used to call the function violate the contract which the function is supposed to fulfill. Let's say the user has a save() button. If the user press the button, foo1 gets called. foo1 checks whether there are changes since the last safe() call. If there are changes it calls foo2. If ...


2

As an alternative to promises you should have a look at the yield keyword in combination with generator functions which will be introduced in EcmaScript 6. Both are available today in Node.js 0.11.x builds, but require that you additionally specify the --harmony flag when running Node.js: $ node --harmony app.js Using those constructs and a library such ...


2

In your case, goto is enough of an improvement that it looks tempting, but it's not so much of an improvement that it's worth breaking the rule against using them in your code base. Think of your future reviewer: s/he will have to think, "Is this person a bad coder or is this in fact a case where the goto was worth it? Let me take 5 minutes to decide this ...


1

First of all, I would say that coding conventions are a place where restrictions on language usage are stored. Otherwise every time people will have different idea about what is familiar for a team and what isn't. When choosing a subset you create a new language. It certainly shares many things with "host" language, but is different. Some things may become ...



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