ITT, we discuss coding styles. I know my own preferences for how far to indent and where to put curly brackets, but what do you, the programmers of the world, have to say about it? Non-C-like languages are also welcome here.

int k_and_r_braces() {
ftw();
// note: 4-space indent and lower_case_underscore_separated
}

class Penis : public Genital
{
	private:
		double dblLength, dblThickness;
		bool blnErect;
	
	public:
		Penis(double length, double thickness, bool erect) : Genital(), dblLength(length), dblThickness(thickness), blnErect(erect)
		
		bool IsHuge();
};


Penis::Penis(int length, int thickness, bool erect)
{}

bool Penis::IsHuge()
{
	return false;
}


Penis* pnsWtSnacks = new Penis(0.5, 0.1, false);

Just stick with your preferences, unless you get involved in a project with several people working on the same codebase. Agree on a single style with them to keep the code more maintainable.

In Ruby, I like to omit the brackets whenever possible and use do ... end instead of curly braces.

# If deemed reasonable, doc of function goes here. Documentation of the program/script as a whole goes just under the shebang-line.
def bla arg1, arg2
    arg1.sub! /bla/, "blu"
    arg2.sub /[aeiou]/, "bbbb".sub("b", "a")
    "a".responds_to? :sub

    # One-liner vs. multi-liner.
    [1,2,3].each do |a| puts a end
    [4,5,6].eacho do |a|
        a.bla!
        a.blu!
    end
end

(Standard 8-space-tab-indent)

Oh yeah, I also like to pass a Hash as a parameter in class-initalizers. Like this:

class Bla
    def initialize opts
        @this = opts[:this] || "something else"
        @that = opts[:that] || 3
        @match = {"desc" => 'href="[^"]*%pattern%[^"]*\.torrent"[^>]*\>([^>]*)\</a\>',
                      "link" => 'href="([^"]*%pattern%[^"]*\.torrent)"'}.merge(opts[:match] || {})
    end
    ...
 end

 b = Bla.new :this => "x", :match => {"email" => '...'}

@that is set to 3 and @match to {"match" => ..., "link" => ..., "email" => ...}.

I like my curly brackets to match up for ease of reading:

int main(int argc, char *argv[])
{
	if (argc < 2)
	{
		printf("What the hell is going on here?\n");
		exit(1);
	}
	printf("Your name is: %d\n", atoi(argv[1]));
	return 0;
}

Function calls/definitions don't have spaces before the parentheses, but things that look like functions but aren't (if while for switch sizeof) do. Indentation uses tabs, which can be assumed to be anywhere from 2 to 8 characters, though I usually set them to 8 when editing. Lines should always be shorter than 80 characters.

I'm with >>6 here, but tabs are set to 4 characters for easier readability. Also, I leave out as much whitespace as possible, because I actually find it less readable when it's there.

I kept my tabs at 4 characters for a long time, but when I used a new editor that defaulted to 8 (and didn't bother to change the default), I discovered it was much more readable that way. With the code spread out, it looks like there's fewer secrets hiding in it... or something like that.

Also it helps me remember to avoid bad code (where "bad code" is defined as "more than 4 levels of indentation"), because text starts to scroll off the right really quickly. I was horrified to load up some old programs and find they had 9 levels of indentation or more. These days I would never do that.

Whitespace is good for indicating precedence:

a = b*8 + (c<<2);

K&R recommend doing it that way, too.

I, for one, like to add spaces between braces:

`// Whatever the function is supposed to do goes here.
int main ( int argc, char *argv[ ] ) {

    // 8-space tabs...
    int lotsOfCapitalLettersInVariableNames = 5;

    if ( argc >= 99 ) {
            printf ( "Thats a lot of arguments you have there..." );
    }

    exit ( 0 );

}`

I guess I just like whitespace (Lots of blank lines, too...). Also, I don't use underscores a lot, I'd name a funtion/variable someName rather than some_name .

http://developer.apple.com/documentation/Darwin/Reference/ManPages/man9/style.9.html

Thanks for the cool link, >>10.

i prefer 1 space indentation... having half the screen occupied by spaces at the beginnings of lines and then having to scroll horizontally seems sorta stupid to me...

That's why you keep the lines under 80 characters. If you're used to writing messy programs with big monolithic functions, it can be hard at first, but never going beyond 4 levels of indentation makes code more maintainable.

That said, one-space indentation has its uses (e.g. C preprocessor code).

I confess that I'm a newbie programmer. I'm learning ruby right now. What conventions do you prefer for naming variables and methods and other things that require naming?

>>15

If you use camelCaps, I'm going to punch you in the face.

I agree with this post.

>>15
Use the ruby style. to_yaml for methods, responds_to? for queries, @some_variable for class variables, SOMETHING for constants, SomeClass for classes and plain variable for miscellaneous variables. Btw, Ruby wants classes and constants to start with a capital letter.

8-space hard tab character tabs (though most of the code I work with nowadays is four or two space, so most of the code I write is like that).

int fun_name() {
　　if (no_spaces_after_conditionals) {
　　　　while (you_live()) {
　　　　　　i_kill_you();
　　　　}
　　}

　　/*
　　 * Oh noes, comments!
　　 */
　　switch (blar) {
　　case 1:
　　default:
　　　　break;
　　}
}

int fun_name(int arg, int arg2, int lots_of_fucking_args,
　　　　　　　　int end of args)
{
}

That being said, I also morph my style depending on language. e.g. even though I don't like reading codeLikeThis, I wrote that kind of code if I'm doing Java, C++, or languages that are similar in feel. For other languages, like C, Python, Ruby, etc., I tend to use the default C style outlined above, if it doesn't have a canonical style of its own. I even write perl like that.