# CamelCase or underscore_separators?



## caesius (Jan 16, 2011)

Which do you prefer for code that doesn't really have a dedicated style (e.g., I've never seen underscores used in Java) I notice that most of the FreeBSD source uses underscores, although that is probably a by-product of being written in C.

Here's my 2 cents:

1. For embedded stuff, all underscores, no exceptions. typedef structs postfixed with a "_t":

2. For "big computer" (i386 etc) programs written in C, I write typedef's in camel case, everything else underscores:

3. For anything else, I probably just follow the existing style (although I'll tend toward underscores if allowed  )

What do other people think?


----------



## graudeejs (Jan 16, 2011)

Simply try to follow style(9)


----------



## wblock@ (Jan 16, 2011)

Following local customs makes for easier interaction with the locals.  This applies to programming languages, driving, and, of course, time travel.


----------



## caesius (Jan 16, 2011)

killasmurf86 said:
			
		

> Simply try to follow style(9)



I still can't find the section that explicitly says to use underscores (or otherwise).

Although, from looking at the FreeBSD source I guess it's kinda obvious which way is favoured...


----------



## expl (Jan 16, 2011)

You should use camel case just for typedefs and maybe for variable names (but I don't) because it is significantly harder to read for anything longer than 2 words and can add confusion. For macros and enums its a no, because they should be written all in capital case to look different from rest of the code.


----------



## UNIXgod (Jan 16, 2011)

It depends on what language I'm working in. Personal preference and style changes over time.


----------



## drhowarddrfine (Jan 16, 2011)

caesius said:
			
		

> The only example of this giving advice was by demonstration:


You need to read through that more carefully. Everything is outlined and I don't think camel case is ever brought up or used.


----------



## caesius (Jan 17, 2011)

drhowarddrfine said:
			
		

> You need to read through that more carefully. Everything is outlined and I don't think camel case is ever brought up or used.



Ah correct. My eyes deceive me. (tempted to blame in small screen, maybe time for an upgrade  )


----------



## sossego (Jan 17, 2011)

Bactrian majuscules


----------



## wblock@ (Jan 17, 2011)

caesius said:
			
		

> I see camel case.



Where?  Maybe you mean something different than this.


----------



## caesius (Jan 17, 2011)

wblock said:
			
		

> Where?  Maybe you mean something different than this.



Yup - my bad 

What about in Python? Isn't it proper python style to use underscores for functions and camelcase for everything else?


----------



## dh (Jan 17, 2011)

caesius said:
			
		

> Yup - my bad
> 
> What about in Python? Isn't it proper python style to use underscores for functions and camelcase for everything else?



It is indeed the recommended style for python - http://www.python.org/dev/peps/pep-0008/

I use the style for C/C++ too (structs/classes CamelCase and functions/methods lowercase with underscore)


----------



## Carpetsmoker (Jan 17, 2011)

I bloody hate space indentation. Above all else, use tabs (or I will personally make sure you will burn in hell).


----------



## phoenix (Jan 17, 2011)

Hear, hear!!  It's fricken' annoying to open a config file and find things indented using spaces, especially weird numbers of spaces like 3 or 5.  And every single one that I open with space indentation ... has a vi config line at the end.  Annoying vi users!!  Great, so your editor is configured to your liking, where it internally converts 3 spaces into "tab"-like indentation that looks just purdy on your screen ... and makes a mess out of everything on everyone else's.

Tab was created for a reason!!


----------



## graudeejs (Jan 17, 2011)

phoenix said:
			
		

> Hear, hear!!  It's fricken' annoying to open a config file and find things indented using spaces, especially weird numbers of spaces like 3 or 5.  And every single one that I open with space indentation ... has a vi config line at the end.  Annoying vi users!!  Great, so your editor is configured to your liking, where it internally converts 3 spaces into "tab"-like indentation that looks just purdy on your screen ... and makes a mess out of everything on everyone else's.
> 
> Tab was created for a reason!!



Wondering, what would you say about my habit of using tabs, but setting them equal to 4 spaces?

In my files I add vim modeline like 
	
	



```
/* vim: set ts=4 sw=4: */
```
This screws up many apps, that assume tab to be 8 chars width.

But come on. 8 char indentation is way too HUGE


----------



## Carpetsmoker (Jan 17, 2011)

This is what I do in my ~/.vimrc instead of spamming files with all kinds of nonsense.


```
set tabstop=2           " Tabs are 2 spaces wide
set shiftwidth=2        " Auto-indent 2 spaces wide
set softtabstop=2       " Still 2...

" We want a tabstop of 8 (instead of 2) for some files (mainly configfiles)
au BufNewFile,BufRead
        \ Makefile*,
        \.vimrc,
        \crontab*,
        \*cshrc*,
        \*.conf,*.ini,*.cfg,*.rc,
        \ set ts=8 sts=8 sw=8
```



> Wondering, what would you say about my habit of using tabs, but setting them equal to 4 spaces?



That's the whole point: Everyone can set their tab width to whatever they like!

If you need to use some sort of visual formatting (e.g. email, *some* config files) you use spaces, then it makes sense.
For code it never makes sense. If you need to do visual formatting to make your code clear, your code is bad.


----------



## phoenix (Jan 17, 2011)

Exactly.  So long as you are using/storing tab characters, I don't really care how you set your editor to interpret it.

Sometimes I configure the editor to show a tab as 2 "spaces".  Sometimes 4 "spaces".  Sometimes I leave it at the default.

But, it has to be *tab* characters stored in the file, and *not* actual space characters.  (Sometimes, I wonder what the original coder of the "convert tabs to spaces" feature in text editors was thinking.)


----------

