PDA

View Full Version : Your Coding Style?



Krak
05-30-2005, 09:55 PM
What kind of coding style do you like to use in the following situations?

1.)

A.)
void Function(){
//myCode
}
//-----------------------------
B.)
void Function()
{
//myCode
}
2.)


A.)
int *myPointer
//-----------------------------
B.)
int* myPointer
//-----------------------------
C.)
int * myPointer

3.)


A.)
if (condition == false)
//-----------------------------
B.)
if (!condition)
4.)


A.)
const char msg[] = "Welcome to Utah.";
//-----------------------------
B.)
const char *msg = "Welcome to Utah.";

5.)


A.)
void Function(int& x){
x = 25;
}

int main(void){
int x=0;
Function(x);
return 0;
}

//-----------------------------

B.)
void Function(int *x){
x = 25;
}

int main(void){
int x=0;
Function(&x);
return 0;
}

My answers would be:

1 - A
2 - A
3 - A
4 - B
5 - A

sand_man
05-30-2005, 10:04 PM
1) A
2) A
3) B
4) B
5) B (A is C++ only)

prog-bman
05-30-2005, 10:09 PM
1) B
2) A
3) B
4) B
5) A & B :)

jverkoey
05-30-2005, 10:10 PM
B
A
B
A
5b wouldn't have the same effect as 5a by the way.

Thantos
05-30-2005, 10:39 PM
B
A
B
B
Depends

prog-bman
05-30-2005, 10:47 PM
Stop trying to be like me thantos.

major_small
05-30-2005, 11:18 PM
1) B
2) A
3) B
4) B
5) A (with obligitory B answer as well)

JoshR
05-30-2005, 11:34 PM
1) B
2) B
3) B
4) A
5) A

Salem
05-31-2005, 12:49 AM
A
A
B
B
Depends...

Iamien
05-31-2005, 01:21 AM
A
A
B
B
Arn't they essentialy the same?

adrianxw
05-31-2005, 01:37 AM
B
A
B
B
B...

nvoigt
05-31-2005, 03:01 AM
void Function()
{
//myCode
}




int* pPointer;




if( ! bCondition )




LPCTSTR lpszMessage = _T("Welcome to Utah.");




void Function( int& nX )
{
nX = 25;
}

int main()
{
int nX = 0;

Function( nX );

return 0;
}


Edit: daveP special: ... and yes, a horse is a miscapitalized HANDLE to an Orse. It should read hOrse.

Sang-drax
05-31-2005, 03:59 AM
1. B (I like symmetry)
2. B (the * is a part of the type name)
3. B
4. none (STL strings)
5. A (use references instead of pointers where possible) (also my code usually compiles, unlike 5B :) )

Stoned_Coder
05-31-2005, 04:23 AM
1. B
2. B
3. B
4. Depends.
5. A

Salem
05-31-2005, 05:00 AM
> 2. B (the * is a part of the type name)
int* p,i;
What type is i?
If you're thinking i is a pointer, think again.

nickname_changed
05-31-2005, 05:46 AM
B.)
void Function()
{
//myCode
}



A.)
int *myPointer

This is because in:
int *myPointer, myPointer2;
myPointer2 wouldn't be a pointer to an int, it would just be an int, so having the * closer to the variable name is clearer.


A.)
if (false == condition)

I like the false first, because condition might be very very long and I'd rather not scroll horizontally.


A.)
const char msg[] = "Welcome to Utah.";




A.)
void Function(int& x){
x = 25;
}

int main(void){
int x=0;
Function(x);
return 0;
}

adrianxw
05-31-2005, 06:24 AM
> 2. B (the * is a part of the type name)
int* p,i;
What type is i?
If you're thinking i is a pointer, think again.
If, as I, you only declare one variable per line, then I can see his point, although it is not as I do it. int* p declares an "integer pointer" so it is associated with the type.

Stoned_Coder
05-31-2005, 06:29 AM
Most C++ programmers seem to prefer the int* var style. Most C programmers seem to prefer the int *var style. Only numbnuts use int * var. As for braces, I always line them up in columns. Its just so much easier to spot a missing one than k&r style bracing. I hate looking at code that has k&r style bracing and reformat it as a matter of urgency. I find its easier to read that way.

FillYourBrain
05-31-2005, 06:35 AM
agreed. k&r I believe was done that way to make it take less lines back when terminal windows and editors were limited. Lined up on the left I believe is called Allman. If you indent the braces and keep them lined up it's called whitesmith.

I prefer Allman. Thus, I guess my answer to the original question is:

1. B
2. A
3. B
4. B
5. poor question

UndeadInsanity
05-31-2005, 07:19 AM
1. A
2. c
3. a
4. a
5. b

Prelude
05-31-2005, 09:30 AM
1 - B
2 - A
3 - A
4 - B
5 - For that example A (assuming C++), but there are functional differences between pointers and references that would make a general answer impossible.

>I hate looking at code that has k&r style bracing and reformat it as a matter of urgency.
I appologize for any code I may have forced you to read with my evil K&R bracing style. ;)

Sang-drax
05-31-2005, 01:28 PM
> 2. B (the * is a part of the type name)
int* p,i;
What type is i?
If you're thinking i is a pointer, think again.
Umm, yes I'm aware of the basic functionality of the language.


More info:
http://www.research.att.com/~bs/bs_faq2.html#whitespace

mrafcho001
05-31-2005, 02:12 PM
1. B
2. A
3. A
4. A
5. B

scoobasean
05-31-2005, 03:00 PM
1.) B
2.) A
3.) A
4.) A
5.) A since B wouldn't work as he has it ;)

CornedBee
05-31-2005, 03:12 PM
1) Mixed. (Linux Kernel Style)

function
{

if(cond) {
}

for(;;) {
}

if(really
long
condition)
{
}

switch(value)
{
case :
{
statements;
}
}

}
(And I NEVER not place braces except on case marks.)

2) int *p1;
int *p2;
(I try to avoid having more than one pointer declaration on one line.)

3) if(!condition)

4) const char *const REAL_STRING_CONSTANT = "...";
std::string initialized_string("...");
(The two given methods are different: one can be edited, the other takes up less space.)

5) Depends. I prefer references. For arrays, I pass std::vector references. For optional parameters, I like Boost.Optional.

Zach L.
05-31-2005, 03:18 PM
1 - B
2 - B
3 - B (w/o the space in before the opening paren: "if(!cond)")
4 - B (w/ * attached to "char")
5 - Depends on the situation... in that one, A

no-one
05-31-2005, 05:01 PM
1.B
2.B
3.B (extracting the space before the opening parenthesis)
4.depends (probably B but usually neither)
5.depends (B most of the time excepting that i would deference the pointer in the function)

>
Most C++ programmers seem to prefer the int* var style. Most C programmers seem to prefer the int *var style. Only numbnuts use int * var.
<

i would have thought the opposite(i would generally be a C programmer, though i use C++ where it fits), though i agree with the third part...

^xor
05-31-2005, 05:11 PM
1. B
2. A
3. A
4. B
5. Depends


I have another question for you. Those of you who never code beyond 80 characters per line, how to you handle such occasions when it's impossible to not do it.


static char *long_function_name(const char *dest, const char *src, const char *options, size_t n)

I can't seem to indent the code with tabs properly if I put a newline after any of the parameters. Using VIM and tabs that take up 8 spaces on the screen.

Prelude
05-31-2005, 05:19 PM
>Those of you who never code beyond 80 characters per line
...obviously haven't done much STL programming in C++. ;)

>how to you handle such occasions when it's impossible to not do it.
When is it impossible to not do it?


static char *long_function_name(
const char *dest, const char *src,
const char *options, size_t n)

It doesn't have to be pretty (though saying that chafes a LOT), it just has to work. You do what you gotta do.

Thantos
05-31-2005, 05:20 PM
I've had no problem using VIM. And you should consider reducing the tab size.

I would go with something like:

static char*
long_function_name(
const char *dest,
const char *src,
const char *options,
size_t n)
{
}
Or something similar

^xor
05-31-2005, 05:25 PM
I meant impossible to not do it without imposing a newline somewhere. My main gripe with it is that I have to use extra spaces along with tabs to indent the code.

static char *long_function_name(const char *dest, const char *src,
const char *options, size_t n)

This example may not have been the best one since it incidently works out ok with 8 space tabs as well.

jverkoey
05-31-2005, 05:26 PM
I prefer to write my functions to save space in their declarations:



#define st static
#define ch char
#define fu st ch*
#define na function_name
#define co const
#define cc co ch*
#define si size_t

fu na(cc dest,cc src,cc options,si n){ /* Code */ }


Look! My function only takes one line of code now! You can move the #define's to a header and think of all the space you'll save!

Prelude
05-31-2005, 05:45 PM
>I meant impossible to not do it without imposing a newline somewhere.
Well, the very definition of a line break makes it impossible to avoid using a newline. It seems to me that your problem is lining things up nicely, to which my response is "tough!". As I said, as long as it works, it doesn't have to be pretty. And any competent programmer will be able to read a reasonable format.

sand_man
05-31-2005, 07:27 PM
Thantos's example looks nice but I don't like the fact that a prototype takes up so many lines so if I have to I use Prelude's example.

Mister C
05-31-2005, 08:53 PM
For what it is worth.

1. b
2 a
3. a
4. a
5. A- scoobasean is right here B would not work needs:


B.)
void Function(int *x){
x = 25;
}

int main(void){
int x=0;
Function(&x);
return 0;
}


Should be *x = 25; :D

no-one
05-31-2005, 09:14 PM
just a thought...




static char *long_function_name
(const char* dest, const char* src, const char* options, size_t n)

B0bDole
05-31-2005, 09:31 PM
A
B
B
B
A

CornedBee
06-01-2005, 03:19 AM
For long functions: with prototypes I do:

type name( type arg,
type arg,
type arg);
I make them line up, which I won't try in the variable-width field here. If they don't line up, I advance the first argument to the next tab stop.
For function defintions, I do

type name(type arg, type arg,
type arg, type arg)
{
}
My rationale is that it's more important for a prototype to be quickly readable. With the implementation, I'd rather save the space.

B0bDole
06-01-2005, 06:32 AM
if it doesnt fit on one line raise your resolution :-p

pianorain
06-01-2005, 07:26 AM
if it doesnt fit on one line raise your resolution :-pOr get a bigger screen.

CornedBee
06-01-2005, 11:57 AM
80 chars are still 80 chars, and that's what I limit my lines to.

Jeremy G
06-01-2005, 01:24 PM
//const char* msg[] = "Welcome to Utah.", "Welcome to Arizona";
//const char *msg = "Welcome to Utah.";
const char* msg[3] = {"Welcome one", "Welcome two", "welcome three" };
/*
int functionVerOne {
// my code;
}*/
int functionVerTwo {
// my code
/*
// my buggy code
*/
/*
// my second solution for buggy code
*/
// my code that usually works as wanted
}


I switch off between languages frequently, so I'm always grasping for syntax in variable declarations. I also have a bad habbit of commenting unworking code bits because I'm affraid the next attempt will be worse and I wont remember the first - better working code to return to. I'm too indecisive.

xxxrugby
06-01-2005, 01:44 PM
1. B)
2. A)
3. A)
4. A)
5. A)

joshdick
06-01-2005, 02:04 PM
void Function()
{
//myCode
}I couldn't live without lined-up braces.


int *myPointer;
For the obvious reason, to minimize the confusion over what's a pointer and what's not.

if (!condition)Some say the other way is clearer, but I don't buy that. If you're a programmer, then you know what it means. Code like
if(bCondition==true)is ridiculous and redundant.
const char *msg = "Welcome to Pennsylvania.";Really, though, I'd rather be using a std::string, but I rarely have a choice at work.
void Function(int& x)
{
x = 25;
}

int main(void){
int x=0;
Function(x);
return 0;
}I'm a big fan of pass by reference.

CornedBee
06-01-2005, 02:36 PM
I should also mention that I have slightly different coding styles in C++, Java, PHP and JavaScript.

Brain Cell
06-02-2005, 08:19 AM
B
A
A (sometimes B)
B
Depends