187
There is a very simple solution to this: remove the commented-out code.
Really, there are only two good reasons to comment out code: to test something/make a fix, or to save code you might use later. If you're testing or fixing something, remove the commented out code as soon as you're done with the test or fix. If you're saving code you might use later, ...
44
Adding to @RobertHarvey's excellent answer I believe there is only one legitimate reason I've ever encountered for saving commented code to source control, even temporarily: in case of non-obvious replacement code which should not or cannot be used right now for some reason. Even then most of the comment should be the explanation, not the replacement code. ...
20
Hmm, I read this question slightly differently from Robert who correctly asserts that commented out code should be removed.
If, however, you are looking for a convention to mark code for later removal, an old favorite of mine is:
//b = false; //TODO: remove
Some IDE's flag //TODO: comments or can be taught to. If not, it's usually a searchable string. ...
6
I use preprocessor directives to remove code, not comments at all:
//comment
active_code();
#if FALSE
inactive_code();
#endif
This makes a very easy thing to search for, and my syntax highlighter treats it as a comment. I can even collapse it into a single line: #if FALSE(...)
You can expand on that idea to have several options:
#if OPTION == 0
...
4
I agree with the answer stating that old code should be removed rather than commented out where possible, however I have observed a convention for those few occasions when commented-out code is needed.
(My basis is C# but this can be applied to any C-syntax language eg java)
// An explanatory comment has a space between the comment marker and the content.
...
4
There is no right answer to this. In a general sense, you actually have three options:
Add an optional parameter,
Add a second function with a different name,
Add a second function with the same name, ie overload the function.
I don't think JavaScript supports the third option, but I'm out of date with that language so may have that wrong. But many ...
3
Here's why you should use function:
The signaling is clear and concise. This is far more beneficial than any of the edge-case hoisting concerns that are listed in the other answer.
You actually want hoisting within modules because as you can see from the code below, the const declaration of tryDoTheThing fail silently and won't be caught until you try to ...
2
I am interpreting the question different still, thinking you want to find commented out code.
C-style code is bound to have semi-colons in it while comment is unlikely to have semi-colons in it. So for single line commented-out code you could use this regular expression:
\s*\/\/[\s\S]*;
For multi-line commented-out code it could be
\/\*[^\;]*;[^\;]*\*\/
...
2
If you use an editor with a compiler running in the background (like Xcode and Clang), you can just try to compile the text of the comment. For example”a concise description” gives errors, “b = false;” doesn’t. You could then use different syntax highlighting.
A simpler method would be an IDE plugin that uses some heuristics, like multiple words in a row ...
2
Yes, I think so.
A compiler parses input (text) in one language and outputs code in another language. It generally requires a parser, some intermediate representation, and a (code) generator. There may be optimization phases that analyze the intermediate representation for possible efficiency improvements. In some sense a compiler is a big ...
1
Based on the description of what you want to do, I would recommend try a template engine before trying to do a full-fledged code-generation exercise. There are various ones available for Python. Jinja is used by Flask so you've already got it in your environment.
1
Other answers have covered variations on the "don't comment out code" theme. But sometimes you do still want it around for reference.
If you genuinely need the code to stay around, a better solution is to surround the code with "#if 0 ... #endif", ideally with a comment to say why. This is the recommended strategy from various coding standards, including ...
1
Here is a partially implemented maybe monad for anyone revisiting.
class Maybe {
isSome;
val;
constructor(isSome, val) {
this.isSome = isSome;
this.val = val;
}
orJust(t) {
return this.isSome
? this.val
: t;
}
map(fn) {
return new Maybe(this.isSome,
this.isSome
...
1
I'd choose option 2 for the following reasons:
A separately named method reveals the intention better than a boolean parameter that you need to look up to understand what it does.
Since you're not modifying any existing behaviour but simply doing something extra at the end, there isn't a good reason to change the original method to take an additional ...
1
Same for any language... Catch the exceptions at the boundary. Handle those errors immediately, or translate them to something your application understands and rethrow them.
Third Party Software
To get anything useful done you need to interact with other software. Unfortunately this means interacting with a foreign understanding of the world.
As you've ...
1
That article has two subtly different general recommendations:
1) "Only applications should have Composition Roots. Libraries and frameworks shouldn't."
2) "A DI Container should only be referenced from the Composition Root. All other modules should have no reference to the container."
You said:
It seems that to do this correctly, the client ...
Only top voted, non community-wiki answers of a minimum length are eligible
