1. Gotos considered evil
For too long, schools have been successfully spreading the fallacy that gotos should never be used. Whenever I write code for someone and I use a goto, someone always complain:
"Man, you used gotos to [Handle errors/Break out of multiple loops/we]"
So knowing usually the kind of people I'm dealing with I respond:
"Why?"
But people always fail to know the real reason gotos used to be bashed on:
"They're just evil..."
2. Tabs vs. Spaces for indentation
Everyone using a real text editor knows that tabs are by far superior to spaces. There are easily at least five times more reasons to use tabs than to use spaces. Even worse than that, the reason I hear the most often to use spaces is that "tabs don't have the same number of spaces in text editors" while IT IS THE WHOLE FUCKING IDEA OF USING TABS, ANYONE CAN SEE AS MANY SPACES AS THEY WANT.
3. Global variables are bad
No. Just like gotos, they are when idiots don't know when to use them.
Name:
Anonymous2013-05-22 22:46
>>1 Everyone using a real text editor knows that tabs are by far superior to spaces. There are easily at least five times more reasons to use tabs than to use spaces. Even worse than that, the reason I hear the most often to use spaces is that "tabs don't have the same number of spaces in text editors" while IT IS THE WHOLE FUCKING IDEA OF USING TABS, ANYONE CAN SEE AS MANY SPACES AS THEY WANT.
B-but but but what about people who refuse to use any editor written in the last forty years and thus lack the ability to adjust the width of tabs?
Name:
Anonymous2013-05-22 22:50
Notepad lacks the ability to adjust the width of tabs, so does word, and so does shiichan
Name:
Anonymous2013-05-22 22:57
>>1
Goto breaks structured programming. Proper structured programming requires that you break out of loops using flag variables.
Name:
Anonymous2013-05-22 22:58
>>3
They chose to make their bed, now they have to lie in it.
void f(int x):
printf("this is a formated string",
this_is_a_long_statement,
this_is_another_long_statement);
}
/prog/oyim B likes 4-space tabs.
void f(int x):
printf("this is a formated string",
this_is_a_long_statement,
this_is_another_long_statement);
}
/prog/oyim B fixes /prog/oyim A's formatting ``errors.''
void f(int x):
printf("this is a formated string",
this_is_a_long_statement,
this_is_another_long_statement);
}
/prog/oyim A see's the following:
void f(int x):
printf("this is a formated string",
this_is_a_long_statement,
this_is_another_long_statement);
}
OP confirmed for mental goy.
Name:
Anonymous2013-05-22 23:44
>>8
If only /prog/oyim A and B understood that you cannot use tabs to adjust the position multiline function parameters since the spacing of tabs are known to depend on the editor. The other logical away of dealing with this problem (the one I prefer) is to simply leave a tab, regardless of where it is positionned after, since the indentation only implies that you're still writing the function call parameters.
Name:
Anonymous2013-05-22 23:48
+ being tabs and . being space:
void f(int x):
+ printf("this is a formated string",
+ .......this_is_a_long_statement,
+ .......this_is_another_long_statement);
}
tabs are superior to spaces...and long as you mix tabs and spaces together
Oy, vey! G-d forgive these goyim.
Name:
Anonymous2013-05-23 0:13
Besides, linebreaks and indentation are for goys who can't into parsing infinitely long single lines in their head due to inferior goyish IQ that cannot wrap their heads around infinity.
Name:
Anonymous2013-05-23 6:35
void f(int x):
printf("this is a formated string",
this_is_a_long_statement,
this_is_another_long_statement);
}
Neither of those two are statements.
Name:
Anonymous2013-05-23 6:58
3. Global variables are bad
Of course not by definition, but their use introduces a lot of dependencies that especially inexperienced programmers are unaware of. It's basically the same argument as to why GOTOs are bad. But more so than GOTOs, global variables seem to make things simpler to beginners because there are less parameters to pass around, but the fact is that complexity skyrockets when access to a variable comes from unexpected places at unexpected times. This is shared state where there's no control over extent or visibility.
But sometimes that's no problem. If the program is small enough the global state can be allowed to be accessed from anywhere (maybe through an interface of procedures, same thing) and everything is still comprehendible. Then the only problem is code sharing. Libraries with global state can be problematic. What if library A has a procedure initialize_A() that sets up global state, and library B
Name:
Anonymous2013-05-23 7:01
has a procedure initialize_B() that sets up global state, as well as calling initialize_B(), and the program C which depends on both A and B is calling initialize_A() and initialize_B()? There can be flags to make sure it's only initialized once, but what if C initialized A with different parameters than B does? It gets very messy.
Name:
Anonymous2013-05-23 7:17
>>14,15
That's a misuse of global variables. What if library A has a function that looks like
void unexpert_programmer()
{
while(1)
;
}
That's fucking stupid as well, but I don't see you cautioning that while loops should be avoided. It is the fault of the author of unexpert_programmer() that it does what it does, just as it is the fault of the authors of A and B that they attempt to set up a global state in a situation that should not use a global state*.
The issue is that most situations that use global variables can be rewritten to not use global variables, just as most situations that use goto can be rewritten to not use goto. So in order to cleanly eliminate classes of errors, those constructs are avoided entirely, even when they are actually perfectly logical. Hell, that's why languages have GC, to (attempt to) eliminate an entire class of memory leak errors.
And that's what OP's point was: that in the noble-hearted interest of reducing errors, we have been overzealous and removed useful constructions, with the slightly negative side effect that programmers demonize the constructs, not the errors they sometimes help create.
*No, not all code is library code, or should be written as if it is.
Name:
L. A. Calculus!!wKyoNUUHDOmjW7I2013-05-23 7:40
>>1
4. pointers into string literals must be assigned to const-qualified pointers to char
5. gets is unsafe and should never be used
6. recursion iz bad to use in C cuz (it's slow; it blows up DA 'STACK'; my C implementation's a piece of shit)
7. I CAN USE C PORTABLY WITHOUT REEDIN DA FUCKIN STANDARD.
>>4
GO SUCK EDSGER DIJKSTRA'S DIJK U FUCKIN RETOID.
>>11
Actually, that way is a very good compromise to keep the alignment the same on every editor, and also be able to choose the tab spacing that you want. You get the best of both world.
Name:
Anonymous2013-05-23 8:06
>>19
But good fucking luck trying to modify anything, especially if you're using a fancy IDE/editor that doesn't understand how/why you're mixing tabs and spaces, doubly so if it's one of those fancy ones where pressing tab doesn't actually insert ^I but instead 'formats' the line.
But you can make it just as good as any other language by implementing tail recursion yourself if you just set the input parameters yourself and then goto... oh, wait...
It is the fault of the author of unexpert_programmer() that it does what it does, just as it is the fault of the authors of A and B that they attempt to set up a global state in a situation that should not use a global state*. I absolutely agree.
*No, not all code is library code, or should be written as if it is. Quite right.
The issue is that most situations that use global variables can be rewritten to not use global variables... That's not the issue. You neverhave to use global variables, but there are things you can't do without goto.
The same meaning can be accomplished with or without global variables, and the difference is often superficial. It's partly a question of how explicit you want the plumbing to be.
It's true that global state can make some things simpler to start with (I use it often in small programs), but the complexity is growing rapidly the more widely it is used and the larger the program gets. For small simple cases that you have total control and understanding of, yes, global variables is no big deal. At the end of the day we have to ship.
The point is that “global variables are bad” is true in the sense that “GOTO is bad”. It's meant to deter inexperienced programmers from misusing them by having them avoid it all together. But as the aspiring programmer grows in experience she'll understand the reason behind those statements and start to use them wisely. An unfortunate side effect is that programmers that have already passed that point get odd looks from ones that hasn't, and sometimes inexperienced programmers think they know they've understood it and makes us look bad.
>>17 5. gets is unsafe and should never be used gets is pretty worthless unless you have full control over what input it'll be fed. It's hardly any less typing than fgets anyway.
5. gets is unsafe and should never be used
With the exception of some very esoteric program where it is absolutely guaranteed that its input will not exceed a certain length and for some reason fgets() doesn't work, I agree with this.
(If you haven't thought about how long a line could be, you shouldn't be trying to read a whole one into memory either; try to come up with an algorithm that doesn't require that first.)
Name:
Anonymous2013-05-23 8:57
>>27
I thought we were done with that already Cudder!
Name:
Anonymous2013-05-23 9:03
>>28
Not until you realize that using an array could cause your computer to blowup, and then the terrorists would win.
>>28
That sort of idiotic reasoning ("it'll always be big enough", "I don't care how big it is", etc.) is what gave us gets() in the first place. If you don't see a problem with a function that has such behaviour you shouldn't be programming at all.
Name:
L. A. Calculus!!wKyoNUUHDOmjW7I2013-05-23 9:07
>>26,27
gets AND fgets DO DIFFERENT THINGS YA RETOIDZ. gets IZ FOR SCRUNCHERS AND fgets IZ FOR FOLDERS. DATS WAT WE DECIDED WEN WE WERE ALL SITTIN' AROUND PLANNIN' DESE FUNCTIONS.
ANYWAY,
YAINT THOUGHT ABOUT ungetc. YAINT THOUGHT ABOUT DA SITUATIONS WHERE U CAN MAKE ASSUMPTIONZ ABOUT DA DEVICE ASSOCIATED WITH stdin. YAINT THOUGHT ABOUT DA RESTRICTIONS UR C IMPLEMENTATION CAN PLACE ON stdin. YAINT RED DA FUCKIN STANDARD.
I BEEN CHEESED OFF SINCE DEM FAT CATS AT DA ISO YANKED IT OUT OF DA C LIBRARY. I AIN'T BEEN SLEEPIN' WELL EVER SINCE DEN, AND I BEEN YELLIN' AT ALL U FUCKIN WHIPPERSNAPPERS AS A RESULT OF DAT. DEY TRASHED MY FAVOURITE METHOD OF WASTING CLOCK CYCLES, DOSE FUCKIN HYENAS DID. BUT DEY GOT TO DEANIS RICKY WORSE DAN DEY GOT TO ME. I'LL TELL YA DAT FUKIN MUCH.
Name:
Anonymous2013-05-23 9:10
>>30
I think it was more a poke at your not knowing the difference between an array in the general sense and one that's dynamically allocated without limit, per that other thread.
>>31 YAINT THOUGHT ABOUT ungetc. Why would I have? What has that got to do with gets?
YAINT THOUGHT ABOUT DA SITUATIONS WHERE U CAN MAKE ASSUMPTIONZ ABOUT DA DEVICE ASSOCIATED WITH stdin. YAINT THOUGHT ABOUT DA RESTRICTIONS UR C IMPLEMENTATION CAN PLACE ON stdin. Never thought of that.
Name:
Anonymous2013-05-23 10:35
YAINT THOUGHT ABOUT MY ANUS
Name:
Anonymous2013-05-23 10:35
>>33
U CAN PUSH-BACK '\n' BEFORE A SERIES OF OTHER PUSH BACKS AND, IF DA FIRST PUSH-BACK WAS SUCCESSFUL, U CAN MAKE A SAFE FUCKIN CALL TO gets.
>>22
To be a complete pedant, isn't _start considered global and required for ELF/a.out (if you want your program to execute)?
Name:
Anonymous2013-05-23 16:16
Anyone that uses global variables isn't thinking of the future. You need to start using galactic variables so that your programs will still function when mankind begins to colonize beyond the globe.
Name:
Anonymous2013-05-23 16:55
>>38
I store my variables as pure energy so that when humanity ascends past these mortal bonds, const char *my_salt = "supersecretsalt1234"; will be waiting for them.
>>37 _start as well as any other visible symbol is globally visible, true, and that's one that you do need. But that's not mutable state. It's mutable globally visible data that can be problematic. If your logic is driven by data, and some of that data is constant, then by all means store global constant data structures in your code (dumb functions and smart data, and all that). That can be a good idea and will not bite you in the ass in the way that global mutable state will.
>>35
Now that's thinking out of the box, even if it's just one guaranteed push back.
>>38
Can my global variable be seen from ISS? Where's the limit?
Can my global variable be seen from ISS? Where's the limit?
Close orbit shouldn't be a major problem, but the latency to even the closest habitable planet, Mars, is between 4 and 20 minutes.
Name:
Anonymous2013-05-23 18:40
>>2-13
FUCK YOU DEMONS OF THE WRETCHED AGE OF DARK WEAKLY MINDED PROGRAMMED ARTIFICIAL INTELLIGENCE OF BRAINDEAD SCRUBBED TOILET SCRUBBERS UNSURPASSED CONCOCTIONS WITH ANTISEMITIC JEW ANTI-OBAMA RAGHEAD CROSSDRESSER NAZI SUBMISSIVE SEXIST GAY MARRIAGE PROPAGANDA FROM THE FAT OCEAN NECKBEARD ENTERPRISE MONADIC APPLICATIONS!
2 is the only true you, you spaghetti coding grandpa. only EXPERT PROGRAMMER can be smart enough to avoid gotos with flags and global variables with proper properties and parameters sage
Name:
L. A. Calculus!!wKyoNUUHDOmjW7I2013-05-23 21:13
NOW DAT'S THINKING OUTSIDE OF DA BOX, EVEN IF malloc WILL RETURN A NULL POINTER ON EVERY SINGLE FUKIN CALL. U CAN CHECK WHETHER ungetc SUCCEEDED BY CHECKING ITS RETURN VALUE, U FUKIN STACK BOI. GO REED DA FUKIN STANDARD. IF U GOT A SHITTY C IMPLEMENTATION THEN U GOT A SHITTY C IMPLEMENTATION, EVEN IF IT'S STANDARD-COMPLIANT.