Oh, you wanted to get off the train? Tough shit, GPS is out.
-
-
-
Where is that??
Commuter trains around London, England — I took them a number of times when I was in the UK (last time being in 2002) and staying with someone who lived in a suburb. Basically it's a carriage (car) with several sets of doors on each side, each giving access to two sets of 2+3 seating, facing each other, with a door between the seats. Each of those doors had a window that could open far enough to lean out of, but also horizontal bars added later to prevent people doing just that, and a purely mechanical latch to keep the door closed. As I recall there’s no latch on the inside, so you had to open the window and reach out to open the door …Ah, here you go:
I am guessing you have no "Health and Safety" people there?
That’s the weirdest bit: the UK seems health and safety mad. There doesn’t seem to be a door in the country that doesn’t have a “FIRE DOOR KEEP SHUT” sticker on it. Well, except these on the trains anyway.
-
Over here every business has to have a certified fire escape route diagram posted in a visible place.
I've been to many a tiny store. Like, 15m2 tiny. With a single door. And a fire escape diagram above the only door.
-
Commuter trains around London, England — I took them a number of times when I was in the UK (last time being in 2002) and staying with someone who lived in a suburb.
They've mostly got rid of those old trains now, and now use ones that have power-operated doors. Which is OK, except that you now have to wait for the conductor to unlock the doors. Some are quick about it, but some… really aren't.
-
I've been to many a tiny store. Like, 15m2 tiny. With a single door. And a fire escape diagram above the only door.
Fire escape plan by Darwin. Seems like a self-documenting sort of situation.
Like assholes who say their code is so readable that it does not need comments. They need to die also...
-
Like assholes who say their code is so readable that it does not need comments. They need to die also...
Explain?
-
Explain?
Just because it is readable to them, as they are the ones who wrote it...does not mean it will be readable to others. Ever come in to a project with sparse or zero comments and it takes you forever to get up to speed? That is what I am talking about. ;)
-
Just because it is readable to them, as they are the ones who wrote it...does not mean it will be readable to others. Ever come in to a project with sparse or zero comments and it takes you forever to get up to speed? That is what I am talking about. ;)
I generally reserve comments for the tricky bits of the code, where it's worth a paragraph explaining what the algorithm is attempting to do, or that we tried a diffferent approach which was O(n2), so now we're doing it this way, that kind of thing....
// Take care to extract any necessary info out of the service before // we delete it, so we can remove the pointer from the lists once it // is fully destroyed. We still want Service::get() to be able to // access the service even from within that service's own dtor - the // implication being that a service dtor should delete any owned // objects immediately before going on to uninitialize the rest of // the object. uint32_t key = service->key(); bool has_update = service->has_update(); // Don't call remove() from ~Service()... service->remove_from_group_() = false; FW_DELETE("Service")(service); // Normally, we'd just delete the service and let everything take // care of itself, but as we are traversing the update list, we need // to ensure that we're left with valid iterators, or we will crash // and burn. (This is why we didn't want to call remove() earlier.) i = remove_internal(key, has_update); end = update_list_().end();
-
I generally reserve comments for the tricky bits of the code, where it's worth a paragraph explaining what the algorithm is attempting to do, or that we tried a diffferent approach which was O(n2), so now we're doing it this way, that kind of thing....
Meh, paragraphs are easy enough to figure out where you have to place them. You had a pain in the ass, so you put a long explanation so that the next guy does not screw the pooch like you did. I mean just a simple line here and there as an explanation of you are doing. Especially if you are running low on creativity for variable and method names. ;)
-
a simple line here and there as an explanation of you are doing
#Lint the code. Will not fail build if it fails. shopt -s globstar eslint -c /var/lib/jenkins/userContent/min_eslint.conf -f [snipped] #Run minification. Will fail build and abort if it fails. cd ./src/grunt /opt/node/bin/npm install grunt #Test the code. Will not fail build if it fails #The config hits the host [snipped hostname], since it's configured okay in the hosts file grunt Test || echo "Unit tests failed, continuing..."
-
That's more like what I was talking about. As a counterpoint, this week I encountered a 718 line .cpp file with not one single fucking comment. The only help was that there were at least helpful things being written to the log file occasionally.
-
As a counterpoint, this week I encountered a 718 line .cpp file with not one single fucking comment.
That's not a problem if the code is self-documenting; I've worked with C# files getting on for that size with few or no comments.Generally, I only use comments when I want to clarify something, or mark a piece of code as a bit y.
-
That's not a problem if the code is self-documenting
If I am spending a lot of time on www.cryptopp.com, it is not self-documenting. ;) If I have to spend a lot of time searching to find where the method is coming from, it is not self-documenting. If I start commenting out large swaths of it, and nothing changes...I don't even know that is...
-
If I start commenting out large swaths of it, and nothing changes...I don't even know that is...
Junk?
-
-
Junk?
Or, at least, you're pretty sure it is.
[size=12]For now.[/size]
[size=10]Until something breaks.[/size]
[size=8]But was it the code you commented out last week that caused the break? Or the code you commented out yesterday?[/size]
-
Until something breaks.
But was it the code you commented out last week that caused the break? Or the code you commented out yesterday?
If I had some comments, I might know. ;)
-
If I had some comments, I might know.
You seem to be doing well at creating your own.
-
-
You seem to be doing well at creating your own.
I know what you were getting at, so no whoosh...but the comments that I have put in are something like:
[spoiler]
//who is the fucking jack fuck mouth breather that wrote this shit?
[/spoiler]
-
I'm dealing with the opposite: A codebase where every single statement, no matter how innocuous or self-explanatory, is commented.
This is a small sample:
for ( int idx = 0; idx < theEnum.length; idx++ ) { // -----> Do we have a match? if ( theEnum[ idx ].getIndex() == index ) { // -----> Assign and bail out of the loop. theView = theEnum[ idx ].getView(); break; } } // -----> Not a valid view? (A bit redundant, but you never know...) if ( theView == null ) return; // -----> Declare the argument type in order to find the constructor of the view. Class[] args = new Class[] { CustomMainFrame.class }; // -----> Initialize the parameter for the constructor. CustomMainFrame param = this; // -----> Create an array of arguments for the constructor. Object[] argObj = new Object[] { param }; // -----> The panel to be instantiated. CustomAbstractView thePanel = null; // -----> Empty constructor. Constructor defaultConstruct = null;
And it all uses that fucking dumb // ----> format for comments.
If the function or class is doing weird stuff I'm very appreciative of a bunch of text explaining what it does at the top, with particular comments in touchy areas. But every single line? Come on.
-
I'm dealing with the opposite: A codebase where every single statement, no matter how innocuous or self-explanatory, is commented.
Ew. Ew ew ew ew ew.
@dstopia said:And it all uses that fucking dumb // ----> format for comments. Fuck this.
Fuck it in the ear ;)
-
I'm dealing with the opposite: A codebase where every single statement, no matter how innocuous or self-explanatory, is commented.
Yeah...that is the far side of wrong on the opposite end of the spectrum...
And it all uses that fucking dumb // ----> format for comments. Fuck this.
More effort to be more annoying. That fucker needs to lay off the coffee just a touch.
-
Yes, and not only that, this application is built ignoring entire features of the Java language, like the fact that we have packages that give us the freedom to use any class name we want in our own custom namespace! Instead of having to prepend every single fucking class name with a three letter prefix! And of course since we don't know what a package is we might as well don't use them to better organize our codebase, especially in a complex GUI application!
Luckily the guy in charge of this is gone, so I'm free to implement saner code conventions.
-
But every single line? Come on.
Technically it isn't every line:
[code]
// -----> Assign and bail out of the loop.
theView = theEnum[ idx ].getView();
break;
[/code]
and
[code]
// -----> Not a valid view? (A bit redundant, but you never know...)
if ( theView == null )
return;
[/code]don't have comments for the break; and return;
-
that is the far side of wrong on the opposite end of the spectrum.
Then there's code that is simultaneously wrong on both ends of the spectrum. Completely self-explanatory statements are commented in the stupidest way possible1, while "WTF is the purpose of this?" code has no explanation.
1 For example, in SystemVerilog
new
is the name of the ctor method (not a keyword), and a derived class accesses its base using the namesuper
. So the code is littered with Captain Obvious comments like these:// New Constructor. function new(string name="blah"); // Super constructor super.new(name); endfunction :new
-
And it all uses that fucking dumb // ----> format for comments.
What the fuck is this shit? This is the first time I saw this. I pray it is the last as well.
-
Me too. What is the arrow for?
-
Technically it isn't every line
Somebody's fishing for a pedantic dickweed badge.
-
What is the arrow for?
I'm guessing it's to draw the reader's attention to the wit and wisdom contained in the brill
iant prose of the comment.
-
-
Obligatory XKCD:
Best part about that? The sentence he's ignoring starts withWell
-
-
What's wrong with the tried-and-trusted method of "Engineer pushes a button, doors are allowed to open"?
Minimum wage.
-
Ah, the 'Comment what not why' pattern. Kill it with fire.
-
Best part about that? The sentence he's ignoring starts with
Well
Well, technically, "start of a sentence" does not necessarily mean "the first word of the sentence".
-
Best part about that? The sentence he's ignoring starts with Well
Technically...
Edit: Hanzo'd. Sort of. By @Rhywden.
-
while "WTF is the purpose of this?" code has no explanation.
Usually the writer of that code has no idea either.
-
Usually the writer of that code has no idea either.
Given that most of this sort of code comes from our off-shore office, I am inclined to agree with you.
-
Then there's code that is simultaneously wrong on both ends of the spectrum. Completely self-explanatory statements are commented in the stupidest way possible1, while "WTF is the purpose of this?" code has no explanation.
The most WTFey code I ever maintained was 1/3rd comments. Every single comment that was of the form:
// 3/10/2001 CEJ
Sometimes you got
// 3/11/2001 CEJ - issue 844
... but the issue tracker had been decommissioned ages ago, so there was no way to find out what issue 844 is.
-
The most WTFey code I ever maintained was 1/3rd comments. Every single comment that was of the form:
// 3/10/2001 CEJ
That is WTFey. Of course it should have been
// 2001/03/10 CEJ
-
Did you at least even know who
CEJ
was?
-
Did you at least even know who CEJ was?
...so you can go release a plague of locusts in his cubicle?
-
Did you at least even know who CEJ was?
I do. That was ten years ago and I still remember his initials. If we ever meet, it's going to be very awkward.
-
Technically it isn't every line:
[code]
// -----> Assign and bail out of the loop.
theView = theEnum[ idx ].getView();
break;
[/code]
and
[code]
// -----> Not a valid view? (A bit redundant, but you never know...)
if ( theView == null )
return;
[/code]don't have comments for the break; and return;
// -----> Assign and bail out of the loop. theView = theEnum[ idx ].getView(); // break break;
// -----> Not a valid view? (A bit redundant, but you never know...) if ( theView == null ) // return return;
Fixed.
-
I have no clue. The guy probably liked comments that way.
He even had a macro for it on his IDE editor.
-
```
// -----> Assign and bail out of the loop.
theView = theEnum[ idx ].getView();
// -----> break
break;// -----> Not a valid view? (A bit redundant, but you never know...)
if ( theView == null )
----->
return;Fixed.</blockquote> FTFY. Well, tried, Duckhorse is being an asshole again.
-
you now have to wait for the conductor to unlock the doors. Some are quick about it, but some… really aren't.
Clearly, there’s your answer for why trains need GPS-operated doors ;)
-
No, we want platform-mounted automatic door openers, so the train doesn't even need to stop.
That's the way to a faster commute