Tag Info

New answers tagged

3

If we interpret this question in its most general sense, the proposed duplicate question has perhaps the best answer you could ever get: Too often when you try to design for the future, your predictions about future needs turn out to be wrong. It's usually better to refactor when you actually know how the needs have changed than to overdesign your ...


0

Well, the most constructive answer I can give you is to choose the style that is more readable - it may save you a "few key strokes" but that is a fixed, one-off cost. Reading your code is something many people will do many times over, so if adding more whitespace makes it easier for them, then the cost-benefit is huge.


0

The old style has been deprecated, you shouldn't use it. There shouldn't even be an argument over which one is better or not. New code shouldn't use the old syntax.


0

JavaScript hasn't needed semi-colons to terminate statements in over a decade. That's because newline characters are considered statement terminators(I believe this is also mentioned in early ECMAScript specs). It really makes a lot of sense, especially since there really is no good reason [that I know of] why JavaScript would need frequent use of ...


0

There are good reasons to keep them in. They are not really optional, JS can add them back in with automatic semicolon insertion when they are missing but that is not the same thing. Douglas Crockford's JavaScript: The Good Parts says on two separate occasions that it is a bad idea. The automatic semicolon insertion can hide bugs in your program and ...


0

Quite an old question, however I'm surprised no one has mentioned: Minification: If you happen to minify a JavaScript snippet that doesn't explicitly end the statements with a semi-colon character, you might end up having a hard time trying to figure out what is wrong with a snippet that was just working before the minification and now doesn't work. ...


0

Javascript is adopting the Python style of scripting. Largely, the semicolons are unneccessary. It is just redundancy. The only time semi-colons are really required is when having several different statements on the same line, which rarely comes as a requirement. Instead, as you must have noticed your daily coding, most of your statements occupy a line of ...


0

I don’t leave them out, but i change the rules when to insert them. The rules most people use is Before each line ending Except the line ends with a } coming from a function statement But only a function statement, not assignment to a function literal My rule is: At the beginning of every single line starting with a opening brace/bracket. Mine is ...


0

What if you auto-generate the file which contains the table declaration? Since it is auto-generated, you never need to diff that legible file itself. Diffing the input file will show only truly changed lines, since you will never reformat the input file to make it more legible. Q.E.D :-)


2

If you look at the version control diff, it's nearly impossible to see what was added as whole table has been rewritten Then don't look at the version control diff. For instance WinMerge, which is free & runs on both Windows & Linux has an option " Line differences with Whitespace: Ignoring all". Couldn't you use that? It won't show those ...


2

One possible kludge which would allow you to keep you change history but align your code correctly would be to comment out the entire existing table. And add a new correctly aligned table after it. This would/should be recorded as just two changes in the source code. After the new table been saved in the repository you can delete the commented out section ...


0

This is what I generally stick to. The main purpose, in my opinion, of having a separate css file is that it may be shared among multiple pages, which may use the styles in different ways. By using css classes instead of IDs, it is less restrictive, letting you not worry about duplicate IDs, while the lower specificity allows easier customisation of the ...


0

There are three errors: Your headers declare a name in a namespace not private to your library which they have no business declaring. You seem to not make sure there's only one definition of it in your whole library. You are trying to shut the warning up instead of correcting that bug. What you should do is one of: Make it a part of your interface. Or ...


2

I typically use one of the two ways. First way is to typedef at the place-of-first-declaration. Second way is to typedef at each place-of-use, and make it only visible to that place-of-use (by putting it inside the class or method that uses it). (1) Put the typedef close to the type that is being wrapped. /* MyAttrType.h */ #include ...


4

Coding styles generally aren't referred to by name unless the name is a clear reference to a published style guide, such as the ones published by Google. Indeed, rarely is the collective styles of indentation, naming convention, alignment, etc. given a single name, and even those individual styles don't have standard names. Based on your description, ...



Top 50 recent answers are included