you dont blame the dog for dogsh*t on the path, blame the owner.
any issues with any programming language is squarley laid at the Programmer, and their attitude to their craft.
aracer: yeah been there, done that, got the mental scarring to prove it 😀
We actually do stuff like that fairly often as we have codebases in a mix of legacy C and Embedded C++ that interface with C# test harnesses.
On the bright side it is fairly easy to sweep it all under a virtual carpet and present a usable interface on top 🙂
you dont blame the dog for dogsh*t on the path, blame the owner.
Fair enough, but in this particular case the creator of the dog (DogGod?) decided to give it a vicious temper, chronic diarrhoea and fourteen bum holes.
stumbled across a bit of code (in the middle of a trivial function to do with multiple currency support) which I'd commented as "I don't know what this does but if I take it out nothing works".
We had a project delivered once where the dev was on the edge of some issues and was about to run off to live with his german girlfriend, all the comments were in German.
Asked a mate for some assistance (he's in here) web page comments came back suitably expletive laden 🙂
Pfft comments. Only losers use comments 🙂
Used to work with someone who was heavily into Gilbert and Sullivan and he used the character's names for variables and functions
stumbled across a bit of code (in the middle of a trivial function to do with multiple currency support) which I'd commented as "I don't know what this does but if I take it out nothing works".
hey i wrote that!!!!!!!!!!!!!!!!!! 🙂
Pfft comments. Only losers use comments
As per the Stackoverflow thread linked to earlier:
[code]// no comments for you
// it was hard to write
// so it should be hard to read[/code]
😀
We had a developer who was meticulous about commenting his code, but without imparting any useful information whatsoever
//////////////////////////////////
// function : DoCalc
// parameters :
// parm1 : integer
// parm2 : integer
// return value : integer
int DoCalc(int parm1, int parm2) {
Yep that's what happens when you have a coding standard that says every function and every argument must have inline documentation, but no one enforces the [i]quality[/i] of those comments.
Still a marginal improvement on the old favourite:
[code]i++; // increment i by one[/code]
(Though the trouble with C++ is you [i]might[/i] actually need that comment, because the ++ operator [i]might[/i] have been overloaded to do something else entirely!)
current thoughts are that comments are only advisable at the prologue level, otherwise variable/method/class names should be sufficient - and if they aren't then refactor until they are.
I had some code to give interviewees and it was all named to be obvious, like currentNode, and previousNode, and the guy suggested the names were giving him problems and he would rename them to something like A1 and A2!
We had a developer who was meticulous about commenting his code, but without imparting any useful information whatsoever
Maybe it was done for an auto documentation creator like javadoc?
^^ some all time classics of all time there
it does remind me now to remove the stuff in the
//Take Out before Finishing or it will run like a dog
//To here
comments
That link is brilliant.
[code]
//
// Dear maintainer:
//
// Once you are done trying to 'optimize' this routine,
// and have realized what a terrible mistake that was,
// please increment the following counter as a warning
// to the next guy:
//
// total_hours_wasted_here = 42
//
[/code]
/* 06/03/1984
just use 2 digits in the year here to save some space
*/
yeah we used to have a coding standard that specified almost exactly the same as that DoCalc() function above.
some code would look like that. some would have an essay explain the intricacies of exactly what each parameter meant.
if the parameters use proper words and not i then it's totally unnecessary.
but then our coding standard also specified a unified layout of where the squiggly brackets go, that was different to almost every normal convention.
and it also specified that C was dangerous and should never be used for embedded code.
we broke almost every recommendation in the standard. includign using C for embedded, writing our own runtime in defiance at being told we had to use VXworks.
and GOTO is a perfectly valid statement tyvm.
edit: oh and one guy would explain exactly what every function does in pseudocode that was essentially syntactically correct Pascal, for every C and Fortran function.
Sadly not, all lovingly handcrafted.Maybe it was done for an auto documentation creator like javadoc?
I survived the great curly bracket war of '96. Grown men almost coming to blows over indentation? Yep.our coding standard also specified a unified layout of where the squiggly brackets go
Still howling at that StackOverflow page.
I'm tempted to try and dig out some of my old code, in a past life I'd to write code which used one language embedded inline in another, which was wrappered in a third.
Knowing that I was the only one ever likely to read it, I used to be prone to leaving myself notes in part to remind myself what the hell I was doing but largely to keep myself amused when writing mundane routines.
I miss const 🙁 and everyone seems to use the form i++ instead of ++i even when they don't need the value of i - winds me up 🙁
auto-generated code featured a lot in the work we did too. but only one level of language wrappering.
that'll be another coding standard infringement 😈
but then our coding standard also specified a unified layout of where the squiggly brackets go, that was different to almost every normal convention.
Ours has normal squiggly brackets but dictates that round and square brackets must always be preceded by a space unless the previous character was a bracket.
Thus producing code that looks different from anything you'd find in a textbook or online, and that every editor you use tries to automatically reformat.
[code]int some_function (int aparam)
{
array_a [1] = other_function (2, 3);
if (multi_array [2][3] == Aclass.thing.othermethod (array_a [1])
{
// etc etc[/code]
Oh and this is enforced for [i]every[/i] language we use.
and GOTO is a perfectly valid statement tyvm.
You are wrong.
[url= https://www.thc.org/root/phun/unmaintain.html ]This[/url] is very useful wrt coding standards.
I survived the great curly bracket war of '96. Grown men almost coming to blows over indentation? Yep
We had a dyslexic C++ programmer which was kind of challenging for him as well as us
Indentation meant nothing to him. Providing the braces matched it didn't matter what it looked like
OK then, GOTO is half a perfectly valid statement 😉
// This shouldn't happen, if it does, then the bits that automagically
// worked when I wrote it have stopped working
Love it when stuff automagically works 😀
OK then, GOTO is half a perfectly valid statement
Can't think of any good reason to ever use (a traditional C-style unscoped) GOTO to be honest.
I'm sure there are some edge-cases on really really tightly optimised stuff, but I suspect even that is pretty dubious given how good compilers are at optimising these days.
It's not inherently evil - but there are usually better ways to do it.
[code]
int SomeFunction ( int aparam )
{
array_a [1] = OtherFunction ( 2, 3 );
if ( multi_array [2][3] == Aclass.thing.othermethod ( array_a [1] )
{
// etc etc
}
}
[/code]
ours would be more like that.
exactly 4 spaces indent. { and } indented in line with the content. 1 clear space in far too many places. CAPS use all set to the same, regardless of typical conventions.
I think only Fortran escpaed the standard, since the starting column for th text is fixed, and you may as well have CAPS LOCK on permamently.
edit: hmm that didn't work as intended... let's try again... edit, sod it, /me blames windows... edit: might have worked, but still blame windows.
Yeah the [code ] blocks don't preserve spaces for some reason - you need to put them in as non-breaking space HTML entities: amperspand followed by nbsp;
*Narrows eyes*
You've missed out the closing bracket of the if on purpose haven't you?
bugger I must be tired, I felt the need to drop it into something and check the brackets....
also got something sent over by a mate that I did a very long time ago now including the following gem
NOT FINISHED - to be completed by Mike Smith
[quote=GrahamS ]On the bright side it is fairly easy to sweep it all under a virtual carpet and present a usable interface on top
A most excellent summary of Managed C++!
[quote=GrahamS ]Can't think of any good reason to ever use (a traditional C-style unscoped) GOTO to be honest.
Oh goodie, I do like a GOTO war. Shall dig out the code somebody used as an example of where one made the code better last time I had this discussion elsewhere...
Yes please Mike 😀
jeeez are we going to get on the
Vi
'v'
Emacs
debate soon and we all know where that will lead
VI RULES!!!!!!!!!!!
Pfffft... all you really need is [url= http://en.wikipedia.org/wiki/Ed_%28text_editor%29 ]ed[/url] 😉
[url= http://xkcd.com/378/ ]Also xkcd[/url]
seems to use the form i++ instead of ++i even
better than "i = i++"
which I have seen used in anger, once.
better than "i = i++"
Isn't that undefined?
[quote=GrahamS ]Also xkcd
😀 Started off using emacs (actually umacs, but it's close enough to count) and was once fluent in that - then I did a lot of work on minimalist systems where that wasn't installed, so ended up having to learn how to use vi(m) which I loathe, but will defend to the death to anybody who dares criticise it. Though I've not recently come across a system which doesn't include nano - the main advantage of which is it's better than vi 😉
[quote=chambord ]better than "i = i++"
Isn't that undefined?
I'm fairly sure it results in i++ as that's a postincrement operator so the assignation should happen first. I'm not sure I'd want to rely on it though. Let's test...
Edit: Yep - using gcc in the latest raspbian it works as I suggest.
Well the result will depend on your compiler.
I've not recently come across a system which doesn't include nano
You need to work on embedded systems more 😀
I've had the pleasure of creating (small) text files using cat or echo because that was all we had room for on the install.
Yes please Mike
And by "Mike" I mean "aracer"
#readingfail
And there we were thinking all this forum was middle management in IT, but this suggests we still have some technical people around!
[quote=GrahamS ]You need to work on embedded systems more
I think it's that the ones I've worked on are either at a similar level to RPi where you have stuff like that, or far smaller and not running on OS at all.
Oh, and the code also works as I suggested in VS2008 which is the other platform I have immediate access to, so I've covered the two most widely used C(++) compilers. Don't think I CBA to start a VM to prove it also works in a different flavour of Linux.
Edit: oh what the heck <fires up Atmel Studio>
Here you go, Graham:
Ok, here is a snipet of code that is much cleaner with the GOTO than
without (BTW it's the only goto in several thousand lines of code
belonging to the same project).[code]// direct_declarator:
// identifier
// | '(' declarator ')'
// | direct_declarator '[' constant_expression ']'
// | direct_declarator '[' ']'
// | direct_declarator '(' parameter_type_list ')'
// | direct_declarator '(' identifier_list ')'
// | direct_declarator '(' ')'
// ;p1 = parse_identifier();
if (p1 == NULL)
{
p1 = parse_lparen();if (p1 != NULL)
{
ITEM *p2;p2 = parse_declarator();
if (p2 != NULL)
{
ITEM *p3;p3 = parse_rparen();
if (p3 != NULL)
{ p1 = p2;
goto lab1;
}push_item(p2);
p2 = NULL;
}push_item(p1);
p1 = NULL;
}
}lab1:
[/code]
