JeffDG
Touchdown! Greaser!
Always remember to document your code!
#define like {
#define man ;}
#define an ;
#define SayBro /*
#define CheckItOut */
SayBro like, this is some rad ****, so CheckItOut
like
a = b
an
c = d
man
SayBro , like who needs help from them compiler choads anyway?
THIS is the way to write CLEAR code. I mean really! CheckItOut
like SayBro this is ShellSort straight out of the white book, but in
a readable form.
CheckItOut man
#define YoDude for(
#define OK )
#define is =
#define AND &&
#define as
#define Do
#define long
#define some
#define make
#define ****
#define FAROUT
shell(v, n) SayBro sort v[0]...v[n-1] into increasing order CheckItOut
int v[], n;
like int gap, i, j, temp;
YoDude gap is n/2 an as long as gap > 0 Do some **** an make gap /=2 OK
YoDude i is gap an as long as i < n Do some **** an make i++ OK
YoDude j is i - gap an as long as j >= 0 AND v[j] > v[j+gap] Do some
**** an make j -= gap OK
like
temp is v[j] an
v[j] is v[j+gap] an
v[j+gap] is temp
man
FAROUT man
SayBro like, B there OB square! CheckItOut
I document my code because I know when I look at it 3 years later, I am going to be scared of it.
You forgot "trivial algorithms."Variable naming standards, code layout, refactoring, etc. all lead to self-documenting code.
However, it is multi-threaded stuff and a nightmare to modify.
You forgot "trivial algorithms."
I doubt too many coders could tell the difference between a shellsort and insertion sort by sight.
And a LOT will not understand the following:
double discr = B*B-4*A*C;
double x1 = (-B+sqrt(discr)) / 2 / A;
double x2 = (-B-sqrt(discr)) / 2 / A;
Comments should also explain when you can get NaN, why one solution is chosen over another, and so on.
I include references to ICDs and other design documents when it isn't obvious or trivial.
Quick comment about comments...
"I can read your code, but I can't read your mind"
I always took that to mean a quick description of "why" is more effective than a comment that repeats the "what" of the code that follows..
Code:#define like { #define man ;} #define an ; #define SayBro /* #define CheckItOut */ SayBro like, this is some rad ****, so CheckItOut like a = b an c = d man SayBro , like who needs help from them compiler choads anyway? THIS is the way to write CLEAR code. I mean really! CheckItOut like SayBro this is ShellSort straight out of the white book, but in a readable form. CheckItOut man #define YoDude for( #define OK ) #define is = #define AND && #define as #define Do #define long #define some #define make #define **** #define FAROUT shell(v, n) SayBro sort v[0]...v[n-1] into increasing order CheckItOut int v[], n; like int gap, i, j, temp; YoDude gap is n/2 an as long as gap > 0 Do some **** an make gap /=2 OK YoDude i is gap an as long as i < n Do some **** an make i++ OK YoDude j is i - gap an as long as j >= 0 AND v[j] > v[j+gap] Do some **** an make j -= gap OK like temp is v[j] an v[j] is v[j+gap] an v[j+gap] is temp man FAROUT man SayBro like, B there OB square! CheckItOut
Every time I find a really stupid or incorrectly implemented piece of code I mark it with an explanation of the problem with the word BOGUS added. The number of O's is a good indicator of how bad the code was.
Example:
/*
* BOOOOOOOOOOOOOOGUS
*
* This code says it averages the bearing angles but you don't average angles by adding
* them up and dividing by n. Also there's a fence post error that skips the last angle in the
* set.
*/
Waste of time. Just fix it.
You really should catch for rootless quadratic equations.
Structured code without object orientation. The kids don't do that anymore.
Of course. Or prove they are impossible, in the comments. Or handle the complex roots.
I didn't give you a whole routine. Those 2-3 lines are enough to trigger the bug eyes; there is no need to make a functional method to do that.
Would it make you happier if I wrapped it in
class BS {
public:
...
}
?
FYI, critical real-time systems are still written in C sometimes, as object orientation can hide performance bottlenecks.
we're nerds.
I document my code because I know when I look at it 3 years later, I am going to be scared of it.
The kids are too young to know even who Seven of Nine was, but the seniors all got a laugh.
We've regulated and overpriced all the fun stuff in the name of safety. There's plenty of us who'd rather shoot bottle rockets at each other than make paper airplanes. Not approved behavior anymore. Heck, most of us would rather do most of the stuff on Mythbusters than watch those two twits do it. But at least they figured out how... Get a video camera and call it a TV show.
If you had ever seen them in action, you would know they are a lot more than two (or five) guys and a camera or two. They do quite a bit of analysis before blowing stuff up.
Had they not, someone would be dead. Much of the stuff they play with is well beyond toys.
We see them at work once a year or so, folding paper with a forklift or kicking helium filled footballs.
You forgot "trivial algorithms."
I doubt too many coders could tell the difference between a shellsort and insertion sort by sight.
And a LOT will not understand the following:
double discr = B*B-4*A*C;
double x1 = (-B+sqrt(discr)) / 2 / A;
double x2 = (-B-sqrt(discr)) / 2 / A;
Comments should also explain when you can get NaN, why one solution is chosen over another, and so on.
I include references to ICDs and other design documents when it isn't obvious or trivial.
We used to fill anvils and pipes with acetylene. The best was when a guy filled a 55 gallon trash bag full tied it up, then lit a shop rag and "hockey pucked" it over to the trash bag BOOOOMMMM!!!!. We lived.
No more so than the various crowds I hang with.
At the last CAP meeting, we had the cadets making model gliders out of paper plates, cups, and popsicle sticks. One of the senior members made a pretty good Enterprise (NCC 1701A). Didn't glide very well, though.
The kids are too young to know even who Seven of Nine was, but the seniors all got a laugh.
Shell v. insertion - yes, I can tell the difference by inspection.
As for why the quad equation up there can get NaN, because if A is zero, that means it's not a quad but a linear equation so there can't be any imaginary roots.
tsk tsk tsk