[QUOTE=aVoN;20490372]For this, I use some sort of "light" Hungarian Notation (since HN is supposed not to be used anymore).
[cpp]class CClassName{
private:
bool m_bVariable;
}
[/cpp]
I only use this on classes, structs etc (m_ + typename + varname). For everything else, I use normal naming like "char thisismycharihavetodosomeshitwith" or "int SomeCoolInt".[/QUOTE]
Fuck you for prefixing. Words cannont express how much this annoys me.
Also, I can't do shit in anything other than Vi. I always forget the keyboard shortcuts for anything else that isn't just straight up notepad.
I'll even fuck shit up in Nano, that has all the keyboard shortcuts shown at the bottom :v:
I'm really specific about my formatting, it has to meet pretty much identical standards or it annoys me.
Looks like this :
[cpp]
int Function1(int arg1, int arg2, int arg3) {
arg1_2 = arg1 + arg2;
if (arg3 < arg1_2) {
return true;
} else {
return false;
}
}
int x, y, z; // coordinates
if ( x >= 0 && y >= 0 && z >= 0) {
Function1(x, y, z);
} else {
cout << "Where's Waldo?"; // what's that got to do with anything?
}
[/cpp]
I use tabs, not three spaces. each set of { } is one extra tab in.
All global variables are declared at the top of the file as well.
Functions are almost always in a different file.
[QUOTE=aVoN;20490372](since HN is supposed not to be used anymore)[/QUOTE]
Largely because [url=http://www.joelonsoftware.com/articles/Wrong.html]it's widely misunderstood and misused[/url]. Prefixes like "b" for a bool or "i" for an int don't really provide any value, so it's no surprise that people got tired of doing it.
I use prefixes to distinguish values from pointers to values: if "foo" is an object or reference to an object, "p_foo" would be a pointer to that object. The purpose isn't to inform me that p_foo is a pointer (that's obvious enough from its declaration), it's to prevent the names from clashing if I want to refer to both in the same scope. By extension, I use "ap_foo" for a std::auto_ptr, and "sp_foo" for a std::tr1::shared_ptr or boost::shared_ptr.
I'll often do this sort of thing:
[cpp]
// Suppose that create_foo() constructs a Foo on the heap and returns an auto_ptr to it.
std::auto_ptr<Foo> ap_foo = create_foo();
// Now I have a pointer to an object, but what I really want to work with is the object itself,
// so I bind a reference to it for convenience.
Foo &foo = *ap_foo;
// Now I can work with foo like the ordinary object that it is.
if (!foo.is_ready()) {
foo.make_ready();
}
foo.set(42);
foo.go();
[/cpp]
[QUOTE=r4nk_;20490723]Fuck you for prefixing. Words cannont express how much this annoys me.[/QUOTE]
I just do this on classes so I immediately know "ah, here in my code, I'm doing shit with member-variables".
Generally, I do not use Hungarian. Just a "lite" version after I worked soo much with the source-engine SDK which is (sadly) excessivly using it.
[editline]11:08AM[/editline]
[QUOTE=Borsty;20498920]I don't know why, but I started to do something like this:
[cpp]
/*
* Main code
*/
int main( void ) {
/* Init */
cli();
/* Port setup */
SET_BIT( DDRD, Led_1 );
SET_BIT( DDRD, Led_2 );
SET_BIT( DDRD, Summer );
CLEAR_BIT( DDRD, Taster_1 );
CLEAR_BIT( DDRD, Taster_2 );
CLEAR_BIT( DDRD, Taster_3 );
/* Init Display */
lcd_init( LCD_DISP_ON );
lcd_gotoxy( 0, 0 );
lcd_puts_P( "Hello World!" );
lcd_gotoxy( 0, 1 );
lcd_puts_P( "Sup?" );
/* initialize PWM for Summer (Timer2) */
// FOC2 WGM20 COM21 COM20 WGM21 CS22 CS21 CS20
//TCCR2 = 0b01110001; // Phase Corrected PWM, OC2, 1:1 scaling
TCCR2 = 0b01101001; // Fast PWM, OC2, 1:1
// PWM Compare value, will be our DAC!
OCR2 = 0;
/* Initialize Interrupt for sampling (Timer0) */
// FOC0 WGM00 COM01 COM00 WGM01 CS02 CS01 CS00
TCCR0 = 0b00001010; // CTC, 1:8 scaling
// Compare value for sampler
// F_CPU / SAMPLERATE / 8
OCR0 = ( F_CPU / SAMPLERATE / 8 );
// Enable interrupt (TIMER0_COMP_vect)
TIMSK |= _BV( OCIE0 );
/* Enable interrupts */
sei();
/* endless loop */
for (;;) {
uint16_t freq = 800;
if ( bit_is_set( Input_Pin, Taster_1 ) )
freq += 100;
if ( bit_is_set( Input_Pin, Taster_2 ) )
freq += 200;
if ( bit_is_set( Input_Pin, Taster_3 ) )
freq += 400;
setFrequency( freq );
_delay_ms( 1 );
}
return 0;
}
[/cpp][/QUOTE]
Too much spacing in my eyes.
One not for /* */ comments: I generally use // comments, because if I want to comment out a huge block of code (for whatever reason), I'd otherwise have the problem of these "one-line-comments" you have making my outcommented code fail.
Example:
[cpp]/*
/* Do stuff */
while(true){
/* other stuff*/
}
*/[/cpp]
You see: The block-comments around all this code fails because of the other block-comments used as line-comments.
[QUOTE=aVoN;20510460]One not for /* */ comments: I generally use // comments, because if I want to comment out a huge block of code (for whatever reason), I'd otherwise have the problem of these "one-line-comments" you have making my outcommented code fail.[/QUOTE]
You can use "#if 0" and "#endif" for disabling large sections of code. Unlike comments, preprocessor conditionals support nesting.
You can even use #else to replace the block of code with an alternate version (e.g. for debugging) and switch between the two by changing the 0 on the #if line to 1.
[QUOTE=Wyzard;20512153]You can use "#if 0" and "#endif" for disabling large sections of code. Unlike comments, preprocessor conditionals support nesting.
You can even use #else to replace the block of code with an alternate version (e.g. for debugging) and switch between the two by changing the 0 on the #if line to 1.[/QUOTE]
Sure, that's a workaround. But that's not what it's meant for. Also: Not every IDE highlights these codeblocks with a different color (e.g. "gray") so you know, it isn't getting compiled later.
I still prefere // for any type of comments and /* */ for getting rid of code I don't want to be compiled (but may need later as reference).
[QUOTE=blankthemuffin;20510819]If we're all posting desired syntax, the superior formatting.
*code*
And yes I just noticed the bad error handling in the first function shown there. And yes this is C99.[/QUOTE]
This is how I format my code.
[QUOTE=aVoN;20514092]Sure, that's a workaround. But that's not what it's meant for.[/QUOTE]
So just like comments, then?
I'm pretty sure #if 0 is superior in every way, other than cosmetic IDE issues.
Everything has to have neat spacing or else it makes me feel like it won't work. Stupid pet peeves.
[QUOTE=aVoN;20510460]
One not for /* */ comments: I generally use // comments, because if I want to comment out a huge block of code (for whatever reason), I'd otherwise have the problem of these "one-line-comments" you have making my outcommented code fail.
Example:
[cpp]/*
/* Do stuff */
while(true){
/* other stuff*/
}
*/[/cpp]
You see: The block-comments around all this code fails because of the other block-comments used as line-comments.[/QUOTE]
Eclipse (and probably other IDEs) got this little nifty feature of selecting all lines you want to comment and then pressing [CTRL][SHIFT][7] and Zing, all lines get a // in front, doing this again removes them.
This is even more easy to see what's disabled than /* */ blocks imo
[QUOTE=aVoN;20514092]Sure, that's a workaround. But that's not what it's meant for.[/QUOTE]
Disabling sections of code isn't what [i]comments[/i] are for. They're for writing, well, comments about the code.
Disabling sections of code actually [i]is[/i] what #if is for. Typically it's used with an expression (e.g #if MSC_VER > 1300) but using a literal 1 or 0 isn't unreasonable.
[QUOTE=aVoN;20514092]Also: Not every IDE highlights these codeblocks with a different color (e.g. "gray") so you know, it isn't getting compiled later.[/QUOTE]
I only disable blocks of code (using either comments or #if) temporarily while debugging something, while the fact that I've disabled the code is fresh in my mind, so that's not a big deal. If I actually don't need the code and don't want it in my program anymore, I delete it. If I want to refer to it later, that's what svn/git/etc. revision history is for.
[QUOTE=gparent;20515174]So just like comments, then?
I'm pretty sure #if 0 is superior in every way, other than cosmetic IDE issues.[/QUOTE]
I'm not going to make you convince something else. That's always a bad idea.
Still I stick with one-line comments for regular comments and block-comments for getting rid of code.
[QUOTE=aVoN;20529958]Still I stick with ,,,[/QUOTE]
I don't really care, we were just suggesting a better way of doing it. It's your time, anyway...
When using {} bracket blocks, like conditions or loops etc.
I [B]HAVE[/B] to finish the start and the end bracket first before coding the block, otherwise it annoys the fuck out of me.
Edit:
Also, so many german coders around here :D
[QUOTE=s0ul0r;20537780]When using {} bracket blocks, like conditions or loops etc.
I [B]HAVE[/B] to finish the start and the end bracket first before coding the block, otherwise it annoys the fuck out of me.[/QUOTE]
Me too!
I'm with you on that one. But not because it bothers me, just because I could easily forget.
Sometimes I need to close them, sometimes I trust my IDE.
I also can't stand this:
[cpp]if(someBool)
doStuff();
else{
doOtherStuff();
anotherFunctionToJustifyTheBracket();
}[/cpp]
While I like not having to use brackets on short if-statements with just one statement to execute thereafter (in rare cases even in one line, such as if(n == 0) return;) I must have the bracket on the if there's an additional else (if) with a bracket.
[QUOTE=ZeekyHBomb;20540396]Sometimes I need to close them, sometimes I trust my IDE.
I also can't stand this:
[cpp]if(someBool)
doStuff();
else{
doOtherStuff();
anotherFunctionToJustifyTheBracket();
}[/cpp]
While I like not having to use brackets on short if-statements with just one statement to execute thereafter (in rare cases even in one line, such as if(n == 0) return;) I must have the bracket on the if there's an additional else (if) with a bracket.[/QUOTE]
yeah sure but that's not a tick :D
[QUOTE=ZeekyHBomb;20540396]Sometimes I need to close them, sometimes I trust my IDE.
I also can't stand this:
[cpp]if(someBool)
doStuff();
else{
doOtherStuff();
anotherFunctionToJustifyTheBracket();
}[/cpp]
While I like not having to use brackets on short if-statements with just one statement to execute thereafter (in rare cases even in one line, such as if(n == 0) return;) I must have the bracket on the if there's an additional else (if) with a bracket.[/QUOTE]
I disagree with you here. Sometimes I'd like to do something like this:
[cpp]
if (someCondition)
foo();
else
ohnoes();
[/cpp]
But C# won't let me :(
[QUOTE=turb_;20548896]I disagree with you here. Sometimes I'd like to do something like this:
[cpp]
if (someCondition)
{
foo();
bar();
}
else
ohnoes();
[/cpp]
But C# won't let me :([/QUOTE]
I've done that often enough.
[QUOTE=arienh4;20548910]I've done that often enough.[/QUOTE]
Oh shit, I'm an idiot. See the revised code sample
[QUOTE=s0ul0r;20541954]yeah sure but that's not a tick :D[/QUOTE]
Why not? I need the bracket on the first if if there's an else (if) following with a bracket.
I would wanna change that snippet to
[cpp]if(someBool){
doStuff();
} else{
doOtherStuff();
anotherFunctionToJustifyTheBracket();
}[/cpp]
[QUOTE=turb_;20548896]I disagree with you here. Sometimes I'd like to do something like this:
[cpp]
if (someCondition)
foo();
else
ohnoes();
[/cpp]
But C# won't let me :([/QUOTE]
That's okay by me. It's just when one of the statements has brackets, I need brackets on all of them.
So either all have brackets, or none, but never some have brackets, some not.
[QUOTE=turb_;20548896]But C# won't let me :([/QUOTE]
No, you did something wrong.
[QUOTE=turb_;20548896]I disagree with you here. Sometimes I'd like to do something like this:
[cpp]
if (someCondition)
foo();
else
ohnoes();
[/cpp]
But C# won't let me :([/QUOTE]
Try
[cpp]
if (someCondition)
foo()
else
ohnoes();
[/cpp]
[QUOTE=Borsty;20551953]Try
[cpp]
if (someCondition)
foo()
else
ohnoes();
[/cpp][/QUOTE]
What, you just broke working code...
[QUOTE=gparent;20551878]No, you did something wrong.[/QUOTE]
That's odd. I swear it has never let me do that before, unless I posted the wrong code snippet yet again
I NEED to have spaces next to all of my operators, except for concatenator and exponent.
Like this:
[code]
a = b + c
-- but
a = b^c
-- and
a = b..c
[/code]I don't know why.
Sorry, you need to Log In to post a reply to this thread.