Code style&formatting thread. Share your pet peeves and

int *ptr;

and

faggot {
statement;
}

learned it from the kernel, it's just easier to read

Allman shills should be banned
1tbs is the only viable option

The second one, obviously. A type is a type, it shouldn't be corrupted by pointer symbols.

>>57229472
People who don't use ternary should go to internment camps.

>>57229490
/thread

>>57229490
this because

int *ptr, i;

is valid and i is not a pointer which you could think with
int* ptr, i;

>>57229472
First one used to confuse the shit out of me when I was learning.
>>57229628
Made me think something similar to this

>>57229545
tell that to the function declaration

>>57229628
multiple declarations per line is horrible style 0/10

>>57229556

If it'll make the code harder to read then no.

>>57229659
>multiple declarations per line is horrible style 0/10

if(x) {
    y;
}

is horrible style too, and yet all faggots use it.
>we should get rid of the faggots.

>>57229659
autism speaks
>>57229628
yeah int *ptr is easier to notice than int* ptr

int *foo;

is the widespread usage, anything else is edgy CS101 angst

File: 1455968129491.jpg (5KB, 208x250px) Image search: [Google]

5KB, 208x250px

>>57229693
>autism speaks
>cannot deal with being wrong

>>57229687

if (foo) {
    bar;
}

anything else is trash unless you are using C# then you can do

if (foo)
{
    bar;
}

this is ONLY acceptable for C#.

>>57229659
>When declaring pointer data or a function that returns a pointer type, the preferred use of ``*`` is adjacent to the data name or function name and not adjacent to the type name. Examples:

char *linux_banner;
unsigned long long memparse(char *ptr, char **retptr);
char *match_strdup(substring_t *s);

Source: https://www.kernel.org/doc/Documentation/CodingStyle

>>57229705
>subjective style opinion
>wrong
so irrationality too on top of autism

>>57229726
>anything else is trash
>retard detected
I am out. I don't interact with retarded people.

>>57229726
Or Swift.

Well you're defining a pointer data type, so naturally the data type declaration should all be together. Since int is an essential part of the data type and the variable name isn't, int* is correct. Use *foo for reference but int* for declaration. It isn't a hard concept.

File: 1456600931014.png (14KB, 679x427px) Image search: [Google]

14KB, 679x427px

>>57229729
>still cannot deal with having lost

File: 1338950346298.gif (535KB, 400x226px) Image search: [Google]

535KB, 400x226px

>>57229472

int * I

>>57229737
You are on 4chan you do everyday, go fuck yourself
>>57229748
This may be true, I don't know Swift style guidelines

>>57229755
t. university freshman

>>57229755
hard truth: the post.

I am new to coding, in fact i just started to learn it. I chose Python.

Anyways, so far so good, but what is the practical difference between one ' and two " ?

>>57229770
Explain your counterpoint then

>>57229490
Personally, I like:

fileprivate func doubleNigger( nigger: Double) -> Double
{
     return nigger *= 2
}

Personally, having the brackets like that help me especially in a shitty editor like Xcode. Anyone, who has programmed a lot in swift, knows what I'm talking about with bracket hell. if let.....

But, I like the other way when coding in Java or node.js in sublime.

Go ahead, call me a degenerate.

>>57229787
yeah the people who put the opening at the end of the first line are retarded

when you line them up they look like

[code
} {

instead of
{
}

{ }
[/code]

int * foo

is the best option

>>57229755
What do you do when you want to declare several int pointers in the same line?

>>57229782
One quote is literal, double quotes is standard containment. Text inside of single quote marks is interpreted literally in that escape characters and variable calls are ignored. Double quotes lets you combine text with escape characters and variable calls. Escape characters are backslashes (or other symbols) that are followed by letters used to format code.

So here's a quick example:

$num = 4
'Single quotes will output $num'
"Double quotes will output 4"
'Single quotes will output \t and that's it'
"Double quotes will output      and that's it"

>>57229822
Is this a trick question?
int* foo, bar, zoo

Otherwise, int *foo *bar *zoo is just more asterisks you don't need.

>>57229822
you buy an xbox, because computers are obviously too hard for you sweety.

>>57229823
ignore the fact that I put a single quote in the word "that's" and fucked up the formatting

>>57229755
Pointers are not data types, junior. It doesn't make sense to group them with the data types, like int or char. Moreoever, if you ever programmed in C outside of classes, you'd know that virtually everyone puts the asterix with the variable.

>>57229829
LMAO, you goof, the bar and zoo you just declared are not pointers, that's why your style is wrong, you jackass.

>>57229838
>a lot of people are idiots, so I will be one too
yeah, no.

>>57229823
Ouh, thank you so much!
No worries, i got the point!

>>57229841
If we're REALLY going there, multiple variables in one line isn't proper anyway, you jackass.

>>57229878
It isn't, but it tells you something about how C works.

>>57229889
Not really. Every language lets you do little improper things, but they aren't peeks into "how it works". If you understand how it works you can determine what the proper formatting is, hence >>57229755

>>57229838
can confirm

former Objective C developer.

>>57229545
Being a pointer is an aspect of the type itself. OP's picture is of a pointer to the integer foo, not of an integer which is a pointer to foo. The first option is the only one that makes sense.

>>57229897
And I can confirm that I've seen people in the professional world do things grossly against proper practice. There needs to be a reason for why you format something a certain why, not just "well people do it this way"

>>57229838
This desu senpai

>>57229659
>multiple declarations per line is horrible style 0/10

I sure love seeing 5+ lines dedicated to declaring variables of the same type

>>57229912
>>57229838
Data type was the wrong word. It's still a classifying symbol and goes with other classifying symbols/words so they need to be together. There is no logical argument for the other way around. Saying that "everybody does it" isn't an argument.

>>57229838
Pretty much every language outside the unique retardedness of C distinguishes pointers in the type system.

>>57229849
A word of advice, junior. One day, the rest of us might have the misfortune of you becoming an actual software ``artisan'' or whatever they call it nowdays. In this position, you will have to, G-d forbid, collaborate with other people when writing code. So you all have to agree on a certain code syntax, lest you produce some unmaintainable mess. Good luck convincing others to use your obscure syntax practices that disagree with all popular conventions -- K&R, ANSI, Kernel, etc.

>>57229908
>Being a pointer is an aspect of the type itself.
Wrong. OP's picture is of a pointer, called foo, to a data of type integer.

>>57229939
>There is no logical argument for the other way around

>>57229628

>>57229944
Hey there, I'm the "junior" you're referring to, and I'm not that anon. My response was >>57229939

>>57229952
Yeah and multiple variables on one line is incorrect.

>>57229967
Not according to the spec it isn't. But if this is just going to be about opinions I might as well say that putting the asterisk with the type name is incorrect.

>>57229988
>just going to be about opinions
>the spec literally uses the word "preferred"

So if the spec itself says that it's a preference matter, why argue over it?

>>57229999
The spec says I can declare multiple variables on one line. Because that is possible and allowed, the asterisk should go with the variable name and for consistency reason that should apply to all code in the code base.

>>57229909
I've had that forced on me by two companies.
I'd say that it's pretty standard style.

Personally, I could give a shit less. They both get the job done.

You get these autists that are more concentrated on minutiae

>>57229939
>classifying symbol
No such thing in C. Can you simply not accept the fact that pointers are special entities and cannot be treated the same way you treat your regular variables? The asterix, in variable declaration, is what people nowdays call ``syntactic sugar''. Or in other words, it tells the compiler that this variable is a pointer.

>>57229472

int* foo, bar;
vs
int *boo, bar;

Should be obvious that latter is correct, for C and C++ at least.

>>57229925
It makes refactoring easier

>>57230034
>cannot be treated the same way you treat your regular variables?
Pointers are really just integers and can be treated as such.

>>57230181
Nope. There are architectures out there that will teach you to honor the difference between pointers and integers the hard way.

>>57230221
Can you give me an example? This is news to me.

>>57230181
That's implementation dependant

>>57230263
Then why would you not implement pointers as integers?

>>57229628
That's an inconsistency for C honestly.

int* x, y;

SHOULD make both x and y a pointer. But it will never get changed.

>>57230310
You'd do that when common sense is your greatest enemy. When you just want to see the world burn.

>>57229727
Why?

>>57230252
I wish I could find the article again to link to it, but I haven't been able to find it so far ... there was a C example program that had a function declared as returning a pointer, while the actual function implementation was defined as returning an int. On a MIPS platform (I think? Or was it ARM?) the processors had special registers for addresses and for integers. So the actual return value was stored in the wrong (integer) register, the caller read the value from the wrong (address) register, and that fucked everything up.

>>57230310
Idk, CHAR_BIT is also implementation dependant even if only meme architectures use a value other than 8. The standard doesn't define it itself so you can't assume it's implementation.

>>57230181
When you say integers, do you refer to the mathematical meaning or to the data type?

>>57230332
It may be considered an inconsitency but it is an intentional one:
>Ritchie:
>Probably the oddest aspect of C compared with other languages outside its immediate family is the declaration syntax, in which (in a way coming from Fortran) a type is mentioned, then variables decorated in a way that reflects their use in expressions. There are many who don't like this, so whether I got it right is an open question.

>still uses pointers
>2016

>>57230332
According to who? You?
It's working as designed.

int *x, *y;

Should make both pointers.

>>57230406
Pointers are good and make efficient programs

>>57230406
You really can't do much without pointers.

>>57230416
If that's how it's supposed to work, then why does

int* x

work too? Still pretty inconsistent.

>>57230352
But they are still integers. They are placed in wrong register because you fucked up and had non-matching definition and body for function - not because they are not integers.

>>57230416
According to logic. You're declaring a int pointer called x and y. By your logic you should be doing:

int *x, int *y;

>>57230432
It works because the whitespace is redundant there. It works because int*x also works.

>>57230447
>By your logic you should be doing:
>

int *x, int *y;

No fucking way I said nor implied any of that. It's your incorrect interpretation of my words.

>>57230447
>You're declaring a int pointer called x and y.
According to who? You? That's your private interpretation, pal.

>>57229472
formatting wars are actually funny, because the compiler give's a shit and it can be adapted to anyone's pleasure automatically.

>>57230441
>strawman
I didn't say integers and addresses are equal or not. I said there are architectures that will teach you to honor the difference between both the hard way. Maybe they are the same, but they cannot be treated as such.

>>57230471
>>57230475
see:
>>57230405

>A closely related aspect is the treatment of arrays and pointers. Given the perenniality of questions about this and the contortions that C++ goes [through] to move away from C on this, it might well be counted as a mistake.

He forgot to add this part. Even the creator admits it's probably a mistake.

Source: http://www.gotw.ca/publications/c_family_interview.htm

Now get the fuck out of here.

I always use reference, did I do wrong?

>>57230503
>it might well be counted as a mistake.
>There are many who don't like this, so whether I got it right is an open question.

>admits it's probably a mistake.

nah

File: 1455812940912.jpg (46KB, 456x461px) Image search: [Google]

46KB, 456x461px

>>57229768
anon, no

neither

type int_ptr is access all Integer;
ptr : int_ptr;

>>57231226
>unironically using meme languages

int*. Yes, there's the weird quirk with bulk declarations but that doesn't matter, C has some weirdness like the type of a string literal being an int.

test

What I do makes me happy.

<label>State</label>
                        <select name="state" class="form-control">
                            <option value="AL"'; if($state=='AL'){echo ' selected';} echo'>Alabama</option>
                            <option value="AK"'; if($state=='AK'){echo ' selected';} echo'>Alaska</option>
                            <option value="AZ"'; if($state=='AZ'){echo ' selected';} echo'>Arizona</option>
                            <option value="AR"'; if($state=='AR'){echo ' selected';} echo'>Arkansas</option>
                            <option value="CA"'; if($state=='CA'){echo ' selected';} echo'>California</option>
                            <option value="CO"'; if($state=='CO'){echo ' selected';} echo'>Colorado</option>
                            <option value="CT"'; if($state=='CT'){echo ' selected';} echo'>Connecticut</option>
                            <option value="DE"'; if($state=='DE'){echo ' selected';} echo'>Delaware</option>
                            <option value="DC"'; if($state=='DC'){echo ' selected';} echo'>District Of Columbia</option>
                            <option value="FL"'; if($state=='FL'){echo ' selected';} echo'>Florida</option>
                            <option value="GA"'; if($state=='GA'){echo ' selected';} echo'>Georgia</option>
                            <option value="HI"'; if($state=='HI'){echo ' selected';} echo'>Hawaii</option>
                            <option value="ID"'; if($state=='ID'){echo ' selected';} echo'>Idaho</option>
                            <option value="IL"'; if($state=='IL'){echo ' selected';} echo'>Illinois</option>
                            <option value="IN"'; if($state=='IN'){echo ' selected';} echo'>Indiana</option>
                            <option value="IA"'; if($state=='IA'){echo ' selected';} echo'>Iowa</option>
                            <option value="KS"'; if($state=='KS'){echo ' selected';} echo'>Kansas</option>
...

>>57231775
It's working!

>>57231297
>unironically retarded

>>57231656

Isn't the type of a string literal const char*?

>>57232011
No. It's const char[].
>inb4 those are the same
No, they are not.

>>57232073
Yes, they are. Read the spec.

>>57232080

#include <stdio.h>

int main(void)
{
    printf("%lu|%lu\n",sizeof("bla123"),sizeof((const char*)"bla123"));
    return 0;
}

Prints out:

7|(4 or 8, depending on the process)

They are not the same. Pointers and arrays are NOT the fucking same.

>>57232080
>I don't know anything about C but I pretend
What is decay?

if ( foo ) {
    ...
} else if ( bar ) {
    ..
}

if (
     foo
  || bar
  && baz
) {
   ...
}

int main(void)
{ printf("hello\n");
  if (1==1) {
    switch (2) {
    default: printf("world\n"); } } }

hehe

>>57232011
My bad, I meant character literal.

>>57232155
What a stupid example. You don't know what sizeof does.

>>57232156
Exactly. Every string literal decays to a pointer. No exceptions. Arrays are pretty much syntactic sugar in C.

>>57232205
No, it's not.

#include <stdio.h>

int main(void)
{
  char x = 'c';
  printf("%c\n",x + 0x100);
}

If it was an int, c wouldn't warp around, or at least it would warp in the same way int does (if overflow was defined, mind you - which it isn't). But it does - this program prints "c", because it's not an int.

>>57232232
>What a stupid example. You don't know what sizeof does.
I accept your surrender.

File: 1436591670032.png (82KB, 261x275px) Image search: [Google]

82KB, 261x275px

>>57229472

Quite a few retards posting in this thread.

2nd is superior because * is also the dereference operator.

int *foo

literally means when foo is de-referenced, it is defined as an int.

>>57232270
You'd be better off opening a book. I suggest starting with ISO/IEC 9899.

>>57232155
>using %lu to print %zu
Nigger

>>57229472
this

int* foo

obviously. the * is part of the type.

>>57232308
I am on a C90 compiler here. In my actual prologue code I have a portable defining for that, but for 4chan I am not gonna bother.

>>57232304
It's alright to lose.

>>57232257
Good job doing a cast there, anon.

try

#include <stdio.h>

int main(void)
{
  printf("%zu\n",sizeof('c'));
}

function() {
    // One line
}

function()
{
    /* Multiple
       lines */
}

File: image.jpg (56KB, 500x332px) Image search: [Google]

56KB, 500x332px

int *poo;

I use

int *ptr

because *ptr is an int. That was how I learned to think about pointer dereference and it typing it that way makes sense to me.

>>57232320
>the * is part of the type
see >>57229628

Do other prefixes like static or volatile go over multiple declarations on the same line?
Such as:

extern int x, y;

Are x and y both extern?

>>57232155
>Pointers and arrays are NOT the fucking same.
I instinctively know this is true, but what is the actual difference?

If someone asked me I'd say "a pointer is a type that contains a memory position, in which a value can be stored and that value can be cast to whatever the pointer's sub-type is. An array can be thought of as a fixed-size set of pointers of the same sub-type that are all contiguous in memory". Am I correct, and is this the best way to explain it without falling into "think of it as..." analogies?

>>57232486
It's an implicit cast that the compiler would show a warning for if information were lost. I don't get any with the highest warning level. I therefore consider this valid code.

>>57232581
An array retains the number of elements it contains. A pointer does not have that information.

>>57232599
It is valid code. That doesn't change the fact that the type of a string literal is int.

>>57232615
I know array-to-pointer decay. What would this concept be named?

>>57232581
No, the way to resolve this is to look at the spec.

>Except when it is the operand of the sizeof operator or the unary & operator, or is a string literal used to initialize an array, an expression that has type ``array of type'' is converted to an expression with type ``pointer to type'' that points to the initial element of the array object and is not an lvalue. If the array object has register storage class, the behavior is undefined.

>>57232635
"Oversight in the development of C that was fixed in C++".

>>57229472

int *foo_thing, *bar_thing;
if (stuff(bar_thing)) {
  foo_thing=otherStuff();
}

here

really, don't mix pointers and ints on the same declaration
the only time declarations should be grouped is if they're directly related, too

>>57229687
anyone who sticks keywords directly next to parenthesis is a heretic

>>57232677
Says a faggot.

>cat pointer.d
void main()
{
        int* x, y;
        pragma(msg, typeof(x), " ", typeof(y));
}
>ldc2 pointer.d
int* int*

:^)

>>57229490
IMO,

faggot
{
    statement;
}

is easier to read. People care too much about reducing line-count.

>>57229823
>$num = 4
>'Single quotes will output $num'
>"Double quotes will output 4"

in bash, not in python

>>57232155
are you trolling

>>57230406
You do know that even modern languages like C# use pointers under the hood? You literally can't do anything without them.

>>57232822
are you retarded

>>57232710
I agree.

public static void main() {
    for (int i = 0; i < 100; i++) {
        if (i % 3 == 0) {
            System.out.println("Fizz");
        } else if (i % 5 == 0) {
            System.out.println("Buzz");
        } else {
            System.out.println(i);
        }    
    }
}

People who write code like this deserve to get shot

>>57233337

>anon fails at fizzbuzz
why should we listen to a word you have to say?

>>57229472
What is the best way to learn a programming language?

>>57233337
kek you can't even into fizzbuzz

>>57233356
Read a book, obviously.

>>57233337
haha what a shitty fizzbuzz

>>57233349
>>57233362
>>57233374
I was obviously just trying to show how shitty code looks. I wasn't trying to write a functioning program.

int *ptr

File: 1456740818711.jpg (5KB, 238x195px) Image search: [Google]

5KB, 238x195px

>>57233392
>obviously

>>57233408
>People who write code [that looks] like this deserve to get shot
Yeah, obviously.

>>57229472
int* foo

it's part of the type, why would you declare in in the variable's name?

File: 1456747352900.jpg (54KB, 535x462px) Image search: [Google]

54KB, 535x462px

>>57233429

>>57233448
epic xD

>>57229787
I use this style with Obj-C with long method names. you can easily see the space between the - and the {

-(void)doSomethingWithA:(id)a andB:(id)b andSomeReallyDumbLongNameForABlock:(void (^)(void))block
{
    // 
}

K&R style
int *foo;
and while we're at it
if(i == 0) {
do_something();
}

I do anything it takes to make my code readable with an 80 character limit.

I often use if/for/while statements with side-effects so I can fit them in a single line without brackets.

>>57233943
Retard.