Indent styles

Is there an indent style that works like this?
voidfoo( type arg1, type arg2, type arg3){ // body}

Would this be a good idea for functions with lots of arguments?

Other urls found in this thread:

astyle.sourceforge.net/
uncrustify.sourceforge.net/
gnu.org/software/indent/
pastebin.com/aWg5p53V
pastebin.com/m40cbK9x
twitter.com/NSFWRedditVideo

PEP8 specifies something like this for any line that becomes longer than 80 characters (preferable) or 100 characters (obligatory).

This is indeed a used indention style, not that I very much like it personally, unless the line is otherwise just too long (in which case I still have multiple arguments in one line).

...

You don't think it makes it easier to separate arugments? Have you never looked at a function with lots of parameters and missed a comma or something like that?

That newline after the opening bracket on foo is so ugly

astyle.sourceforge.net/
uncrustify.sourceforge.net/
gnu.org/software/indent/

But if you don't do it then the first argument does not line up with the rest!

Go back

The third line really unnerves me.


You forgot clang-format.

I forgot it on purpose.

Frankly, no, I haven't. My editor highlights the types, so finding where an argument starts is trivial due to the colored type.

Does it highlight all of these correctly?
int __stdcall NewMessageBoxA(HWND hWnd,LPCSTR lpText,LPCSTR lpCaption,UINT uType)

No, it doesn't. That said, the ALL_CAPS thing kinda serves as it's own highlighting. Yes, I can see myself having a bit of trouble reading these (partially due to the lacking space after the comma), but fortunately haven't found a lot of such code yet.

So you are banking on the fact that most code you encounter will be written well enough to not warrant this sort of indent style?

The indent style is not something I can choose when I'm reading someone else's code. In my own code, I don't usually use typedef or #define any type at all. Besides, most functions don't have enough arguments to make this style worth it, and I would either use it for all functions, or not at all.
I believe this:
int function(int x){}
Looks better than
intfunction( int x){}

But I also think this:
const struct*mylib_thisfile_static_dicks( const struct *some_struct, unsigned long long very_integer, signed short dick, int x, int y){}

Looks better than:
const struct *mylib_thisfile_static_dicks(const struct *some_struct, unsigned long long very_integer, signed short dick, int x, int y){}

The only difference being that I don't find myself in a situation like the second example often enough for it to be worth it. And even the second example's "worse" code isn't too bad as per readability.

That said, yes, the indentation style in OP exists, it's used by some people, and it is nice to read. I wouldn't use it, for the reasons I've stated. Now remains a question nobody else can answer for you: Would you?

Indentation of the last block of code kinda failed. I meant to indent the second line to just one space after the opening "(":
const struct *mylib_thisfile_static_dicks(const struct *some_struct, unsigned long long very_integer, signed short dick, int x, int y){}

who cares for indentation style, if the compiler ignores space?
just don't use space, use tab exclusively, and you should be fine.

I write my shit in one line, because compilator doesn't care

1) stop_with_the_fucking_embarrasinglyLong_function_Names(struct struct_tag_t *...
2) there's always the pre-ANSI format
const struct youmissedthis *mylib_thisfile_static_dicks(some_struct, very_integer, dick, x, y) const struct missedthistoo *some_struct; unsigned long long very_integer; signed short dick; int x; int y;{...}

How about some sort of middle ground?
void poo( char *where, int amount){}

Keeping the type on the same line as the function name makes it look nicer imo.

Because who needs type safety anyways?

I think you missed something there bob-o.

The point was that if some names are a bit longer and/or you have more arguments than fit on your screen, the style in OP looks better, mr autismo.

I guess that looks alright. Can't see myself getting used to that though.

>>>/java/

Real world(tm) code coming through.

pastebin.com/aWg5p53V

pastebin.com/m40cbK9x

Which do you find easier to read?

You clearly haven't made anything more complex than fizzbuzz if you haven't seen function names longer than 16 characters.
I was exaggerating for the sake of the example.

Real world my ass.
Nobody outside of a chan would have eye cancer-inducing comments after the opening bracket.
Please put the comments before the function definition.

It's not my code though. I just coped it.

I like to do it like this

int copyBuffers(char* buffer1, char* buffer2, int buffer1Len, int buffer2Len){ // code}

I know style is subjective and all, but the end goal is to make it easier to read, and taking up so much vertical space makes it so you need to look further up and down to read a single function, and you also can't fit as much on the screen at a time, which personally I find to be very annoying.

Honestly, pretty much any editor should automatically highlight argument lists to make them easy to read anyway. And if you save yourself one line of formatting, you can fit in a one-line comment at the head of the function instead, which is usually far more beneficial to readability than any fancy indentation. jk i'm sure all your code is "self-documenting"

Please put a newline before that closing paren.
void poo( char *where, int amount){ /* ... */}
That is more visually appealing IMO.

I think this is better IMHO

void poo( char *where, int amount){ /* ... */}

That works too. I suppose for consistency you could do either that, or what I had but with the open brace on the same line as the close paren.

Who is this semen demon?

Here's how I could do it:
this.Thread.Content = Autism;

...

That toy example works fine, but once you have a more complex return type like and longer function name. It can get well beyond 80 chars.

I know, but I only ever write pseudo-code anway. ^_^

bravo faggot you have alzheimer