How do YOU style and format YOUR c code? include indentation, curly braces, etc...

Those are actually proper recommendations:
>Use /* */ for comments, not //
extensions implemented in C99 and C11 languages should be avoided
>All variable declarations at top of block
ditto
>Do not use bool types (stick to integer types)
ditto
>Return type and modifiers on own line
this makes function names vertically aligned

>extensions implemented in C99 and C11 languages should be avoided
Why?

>extensions implemented in C99 and C11 languages should be avoided
why? c89 is 29 years old ffs, and it has many defects (strict aliasing rules being imprecise, missing safe variants of standard functions, ...)
>All variable declarations at top of block
why? putting your variables by the code that uses them is more easy to navigate
>Do not use bool types (stick to integer types)
why? by specifying bool, you tell the reader that you are interested in only false/true, rather than 25, 26 and 27. it specifies the value domain you are interested in, which is the point of type system in the first place

>c89 is 29 years old ffs, and it has many defects (strict aliasing rules being imprecise, missing safe variants of standard functions, ...)
Yes, C89 is old and ill (i'm not even talking about non-ansi C), but C99 and C11 took a leap in different direction long enough to be considered a separate language branch similar to objective C. Languages using "C subset" can not use "C99 subset". That is C99 and C11 are basically not C anymore. (Though i admit that a lot of changes are definitely great).

>why? putting your variables by the code that uses them is more easy to navigate
extensions implemented in C99 and C11 languages should be avoided
>Do not use bool types (stick to integer types)
extensions implemented in C99 and C11 languages should be avoided

you wrote lots of opinions but none of it is argument
all i see is "i dont like C11 so you shouldnt use it", without any real explanation why exactly

C89 is very harmful and should be definitely avoided unless you write for ancient systems

>In declaration of pointers the * is adjacent to variable name, not type

go die in a fire :)

you first sepplesfag

lots of arguments against stuff here, but what is considered a generally solid style to follow? the linux one? I've only stuck with suckless because I messed around with their software a bunch and just carried over the style to my own stuff

Attached: 1457188303310-1_001.png (300x300, 148K)

Would declare variables on use if I wasn't forced to program in C89.

void vmm_on_rdev_irq(struct remote_device* rdev, const uint32_t* bitfield)
{
int i;
struct vm_device* vd;
struct vm_irq* triggers;
int num_triggers;

vd = rdev->vmm_dev;
if (unlikely(vd == NULL))
{
rdev_warn(rdev, "Interrupt triggered on unattached remote device");
return;
}

spin_lock(&vd->lock);
if (unlikely(vd->irq_index == -1))
{
spin_unlock(&vd->lock);
rdev_warn(rdev, "Interrupt triggered but IRQ index is not set");
return;
}
else if (osif_assert_warn(vd->irq_triggers[vd->irq_index] != NULL && vd->irq_count[vd->irq_index] > 0))
{
spin_unlock(&vd->lock);
return;
}

triggers = vd->irq_triggers[vd->irq_index];
num_triggers = vd->irq_count[vd->irq_index];

for (i = 0; i < num_triggers; ++i)
{
u32 index = i / 32;
u32 offset = i % 32;

if (!!(bitfield[index] & (1 lock);
}

>unlikely
What're these, macros that use builtins?

>All variable declarations at top of block
>Do not mix declarations and code
trash

>all i see is "i dont like C11 so you shouldnt use it", without any real explanation why exactly
You need to stop imagining things, i wrote that "a lot of changes are definitely great" and "C99 and C11 are basically not C anymore". You know, you can't just use _Bool, generic or threads because C++ or Ada (and even seemingly compatible C code) are not aware of those things.

>What're these, macros that use builtins?
Yes

elixir.bootlin.com/linux/latest/source/include/linux/compiler.h#L48

That's because they're not C.
>Muh sepples subset
C++ forked from C before C was even standardized - and it's still not even remotely compatible with C89 because of all its own keywords and minor incompatibilities (auto redefinition, implicit void* conversions, char literals are chars)

Kek, that's really awful. Looks like indentation error

just b urself

by that logic, you shouldnt be using C89 either because youll get buttfucked by things like restrict as well

C and C++ are not compatible languages and one shouldnt be crippled because of the other

It's literally perfect and you know it.

>sepples
the * is a type declerator, it goes with the other part of the type declaration not the identifier, now go in the fire :)

>I have never written a C parser.
>I can't even parse C in my head
Watch this, I'll blow your mind.
void (*p)(void);

>how do YOU style and format YOUR c code? include indentation, curly braces, etc., as well as header/project and file/directory structures.
Here is exapmple:

reeee

Attached: 1503274999044.png (1700x600, 181K)

There is a Hackaton in my university at the end of November.

Can I learn C in 1 month? And if yes, what books, tutorials, exercises should I follow?

I am already proficient in Java, and C#.

If you're smart maybe.

For smaller projects with only a few files (which are the majority) i usually group all my includes and global constants in an include.h or something. Only if i need to include some stuff specific to one .c file i make a corresponding .h file.

Functions are like this

void func(int arg)
{
}

checks like this

if(a < b){

} else if(OP == "fag") {

}

Depends on what you want to hack on.
If you set out to write some drivers or low level stuff it's probably a stretch.
Go anyway, worst case is you learn something new.

I use the following shell script:
#!/bin/sh

indent *.c *.h -bl -bad -bap -bbo -bc -bl -blf -bli0 -bls -bs -cs -i4 -nut -psl -sbi0 -sc

You guys are string to approach my point. It is important to avoid incompatibilities because C is the thing that glues other languages and / or system together.

>by that logic, you shouldnt be using C89 either
I never wrote "not using c99", i wrote "extensions implemented in C99 and C11 languages should be avoided". It is ok to use c99 but avoiding features that may be incompatible with c89 or c++. That is properly written C code should work fine and produce expected result when compiled as non-ansi C, c89, c99 or c++ and interface part should be usable from other languages. Previous statement obviously implies some degree of indulgence but the idea to be as conservative as possible.

int* p, x;
is x a pointer or not? now you see why the * belongs to the variable name.

You can not be proficient in Java and C# without reasonable experience in C.

Multiple declarations was a mistake.

Each variable declaration belongs to its own line so you will never have to deal with shattered typenames or mixed-in initializations:
char a = 'b', b[] = "whatever", * const c = b, ( * d )[3] = NULL; /* gay */
char a = 'b';
char b[] = "whatever";
char * const c = b;
char ( * d )[3] = NULL;

Or you can just write C as it was intended to be written so you don't have to kneecap yourself with bandaid fixes for your own antipatterns.

I wouldn't say it was a mistake. Multiple combined declarations are shorter and allowed to save quite some bytes of RAM / disc. That was very important advantage back then. But they are definitely a good target for deprecation and should be avoided today, that's for sure.

>Or you can just write C as it was intended to be written
Multiple declarations is a mistake and should not be used. There's a reason why it is discouraged in most programming styles, including the Linux kernel programming style:

>[...] use just one data declaration per line (no commas for multiple data declarations).

>Multiple combined declarations are shorter
Code should be readable, intuitive and concise. Optimise for this rather than being as compact as possible.

>and allowed to save quite some bytes of RAM / disc.
Okay, I'll concede that a handful of bytes did probably matter when we were still using punchcards, but it definitively doesn't matter these days, yeah.

Just to clarify:

>inb4 but the kernel programming style guide also advocates placing the asterisks with the name rather than type
Yes, indeed it does. I'm simply arguing that multiple declarations on a single line should be avoided.

>now you see why the * belongs to the variable name.
How would you write the following then?
int * const i;

Well, by inference, I know some basics concepts of C that have been passed to C# and Java.

That piece of code looks bulky and all over the place, I'd stylize it as follows:
public static void
print (int num[], int n, String mess)
{
int j;
System.out.println (mess);
for (j = 1; j

>how do YOU style and format YOUR c code?

#!/bin/tcc -run
#include "io.h"

s32
main(u32 argc, u8 **argv)
{ for (u32 i = 1; i < 10; ++i)
{ if (i % 2)
{ print("%i\n", i);
}
else
{ print("ok\n");
}
}
//this is a comment
return 0;
}

Attached: 1539283099027.png (563x563, 200K)

>/bin/tcc -run
What's the point of this other than novelty? I don't see why you'd compile a C program except if you needed performance, in which case you'd want to use a modern optimizing compiler rather than tcc. If you need a script, just make a script.

I stole the kernel .clang-format config file (with a few modifications, like increasing the maximum line length) and automatically format all my code with clang-format. Saves fiddling around with manually formatting.