[ art / civ / cult / cyb / diy / drg / feels / layer / lit / λ / q / r / sci / sec / tech / w / zzz ] archive provided by lainchan.jp

lainchan archive - /λ/ - 20415



File: 1480050278609.png (66.48 KB, 300x129, wG51k7v.png)

No.20415

Use whatever brace style you prefer.

But not this.

Don't do this.

Seek help instead of this.

  No.20416

File: 1480050506736.png (27.62 KB, 200x129, microexpressions-disgust.jpg)


  No.20417

File: 1480050621918.png (129.89 KB, 200x113, mpv-shot0011.jpg)

Literally why?

  No.20438

File: 1480085492290.png (110.06 KB, 200x79, normie style.png)

I've used this normal person style for years. I've never seen anyone use op's pick. Where did you find that abomination?

  No.20440

Clearly, somebody wanted to pretend they were using Python. That's horrifying

The best indent rule is clearly 1TBS but with function opening braces on the same line as the function. KNF, Linux, and Allman are also fine.

However, if you use Whitesmiths or Lisp indentation (in C), you should be derezzed from ever writing C ever again. GNU style is pretty bad as well, but not as bad.

  No.20441

File: 1480089546012.png (297.32 KB, 160x200, 1472341754221-0.jpg)

>>20438
This will be the last time you defile the holy saints K&R and their holy tenets of C code style.

curly brackets only go on the second line of the block when defining functions, with other code blocks you stick em at the end of the first line

  No.20449

>>20441
I know how K&R wrote there C code, I just don't like it. The way I do it, in some cases, looks less obfuscated.

  No.20450

I like the way they do it in Java.

  No.20452

I like the way they do it.

  No.20456

With Lisp, I use Lisp style.
With Forth, I try to fit a word to a line and factor when necessary.
With APL, I try to fit the entire program on a single, long line.

With other languages, I'll use a combination of these.

  No.20466

File: 1480178672675-0.png (42.06 KB, 200x166, scrot-c++.png)

File: 1480178672675-1.png (54.23 KB, 159x200, scrot-racket.png)

My most recent C-like code is a sort of operating system (I've barely worked on it though). I'm using K&R style.

Mostly I'm working on my lisp-fu and writing a webserver in Racket, letting emacs indent my code, and using Racket-style [] instead of () where appropriate.

  No.20468

>>20466
>2 tab stops instead of 8
use 8 you pleb: https://www.kernel.org/doc/Documentation/CodingStyle

  No.20473

>>20468
>tabs
>not spaces

  No.20475

>>20473
>spaces instead of tabs
>convulsions intensify

  No.20476

>>20473
this nigga use tabs for alignment

  No.20477

>>20476
is dis a 4 or 8 spaces type nigga?

>>20473
>autism intensifies

  No.20478

>>20473
a tab is one byte, which makes it four times as efficient as 4 spaces.
there is literally nothing wrong with tabs for indentation and spaces for alignment
>>20438
if/for/while is not a function

  No.20481

>>20478
Tabs suck. Eight spaces is comically to large, and even if you adjust your TS, your code will be virtually unreadable anywhere outside your computer, because most people don't.

  No.20494

In C I use two or four spaces indentation, and braces on the same line as the expression. If a conditional or loop is short enough I put it in the same line and remove the braces.
int main(void) {
for (int i = 8; i; --i) {
if (i % 2) puts("even");
else puts("odd");
}

return 0;
}
Languages that have similar syntax usually have a well-defined standard which I usually abide to, if I had to use C# I'd put all the braces after newlines like in >>20438 even though I find it abhorrent.

  No.20496

>>20481
Tabs are 8 characters, and thus indentations are also 8 characters.
There are heretic movements that try to make indentations 4 (or even 2!)
characters deep, and that is akin to trying to define the value of PI to
be 3.

Rationale: The whole idea behind indentation is to clearly define where
a block of control starts and ends. Especially when you've been looking
at your screen for 20 straight hours, you'll find it a lot easier to see
how the indentation works if you have large indentations.

Now, some people will claim that having 8-character indentations makes
the code move too far to the right, and makes it hard to read on a
80-character terminal screen. The answer to that is that if you need
more than 3 levels of indentation, you're screwed anyway, and should fix
your program.

In short, 8-char indents make things easier to read, and have the added
benefit of warning you when you're nesting your functions too deep.
Heed that warning.

  No.20498

>>20468
I'm working on someone else's 8-space-tab C++ project and I can tell you it's ugly as all sin.
I was originally planning on doing 4-space-tabs but I found 2-space-tabs to be a lot better.
Maybe I'm just used to Lisp where everything is kind of crammed together and deep indentation is common.

  No.20499

>>20481
>Tabs suck
I've never understood this huge meme. I tried using spaces instead of tabs to see if there was any difference and the only difference I ever got was having to hit backspace 3 extra times

  No.20501

>>20499
From your post, I gather that your tab stop is set to four.

Set your tab stop to 8. Look in horror. This is what everyone else sees when they look at your code.

Now you know.

Also, if you need to backspace through your indent by hand, your editor is like kicking dead whales down the beach. You should be able to go up and down indent levels with a single command. Or have your editor handle it for you at block delimiters.

>>20496

First off, if you need 24 characters of indentation to tell you that your code is garbage, than you suck.

Secondly, even one level of tab indent is irritating.

Finally, there are other languages where tabs don't work well for indentation. Like Lisp. I'm not changing my indent style every time I change languages.

Also, does anybody tab indent Lisp? If you do, actually fuarrrk you. You are what is wrong with computing.

Well, you, x86, the win32 API, and parts of POSIX, anyways. And systemd.

  No.20531

>>20501
because my tab stop is at four, whenever I see other people's code that uses tabs, it looks just like mine, indent-wise.
Also in vi/vim, the problem is precisely that when I end a function definition and want to write the closing brace I have to delete 4 spaces instead of one tab, which is awful.
I'd say that a programmer has his editor set up to look the way they want it.
Tabs are widely used for indenting and if you don't like looking at 8-char tab stops then you set it to 4, is that hard to grasp?

  No.20537

>>20456
This isn't brace style you tard.

>>20494
Stealing your example to show my style. I use 8 for my tab width, and spaces align my code.
int
main(void)
{
int i;

for (int i = 8; i; --i) {
if (i % 2 == 0)
puts("even");
else
puts("odd");
}

return 0;
}

  No.20547

>>20501
>Set your tab stop to 8. Look in horror.
All that happens is that the indentations push farther to the right. If none of my files mix tabs and spaces for indentation, then changing the tabstop should change literally nothing except how exaggerated nested blocks are.

If the files mix tabs and spaces, then yes, horror shows begin. But that's why you pick a standard and stick with it.

  No.20549

I notice that generally style arguments happen over C code. I know this is an old debate within the community, but why don't other communities (like Lisps or functional languages like Haskell, even smaller language communities like Forth) care at all? Lisp makes sense to me (the community just agreed on one style) but others aren't consistent but don't care. Does it really matter that much for readability in C or C-likes?

  No.20550

>>20549

because you can manage C code anyway you want, unlike java's com.package.in.a.folder.in.a.project. Which can produce really tidy code (redis, linux filesystems, reactos) or unmanageable mess (most botnets).

  No.20551

>>20550
What does project management have to do with style choices?

  No.20553

>>20551

idkactually im really baked and just wanted to rep a few good libraries. though id argue some style choices are reflected in management (global vars for instance), and higher languages like to marry Class <--> Folder pretty tightly.

  No.20554

>>20549
The C language has a great deal of syntactic sugar which, asides from causing cancer of the semicolon, can lead to hard to notice bugs, like the Apple goto fail bug.

Another reason is the lack of available program formatting routines for many. UNIX and C are designed with a mindset that shuns automating tools to a large degree.

The last reason I can currently remember is that C's syntax isn't particularly good to work with anyways. With Lisp, things are consistent and program formatters became available to most users early on. With Forth, simplicity is the goal and so it makes sense to write short routines that fit on very few lines, not even mentioning how the stack can complicate this. With C, there's too many opinionated people, the code formatters support several different styles now, and everyone has their own opinion about how to make it look decent.

  No.20558

>>20549
it doesn't matter really. People just have preferences and stick to the but some like to argue about petty soykaf like subjective styles.
It's only important that it's consistent through the source, for the rest, it doesn't aid nor diminish readability

  No.20563

>>20554
>>20549
I suppose what might contribute to it as well, is that changes in indentation/braces in C-style are pretty drastic when compared to style choices in other languages.
For instance compare these very trivial programs
(define (numbers i)
(when (<= i 10)
(displayln i)
(numbers (+ 1 i))))
(numbers 1)

int main (void)
{
for (int i = 1; i <= 10; i++) {
printf("%d\n", i);
}
return 0;
}

Think about what little stylistic changes could be made to the lisp code (if any at all), and then think about what changes could be made to the C code. Braces on their own line? Make the indent with 2? 8? Braces on their own line? Remove braces from the for loop? int declarations outside the for? Return type on its own line?
Even without taking into account decisions like ++i vs i++, return type for main()? Omit return 0?
These very much affect the appearance of the C code, and to many that affects the readability as well.

  No.20677

>>20478
Considering how nested my fors, structs, and ifdef's were, in my case not breaking it into functions would have made it really hariy and difficult to debug.

  No.20678

>>20677
EDIT: Forgot to mention, it's a header file anyway. Sometimes you want to reuse for's.

  No.20715

>>20501
Set my tabstop to 8 for the first time. Much more easy to see indentation and see connections. If someone don't like it when they read my code, they can change their tabstop to 4 or 2.

  No.20718

>>20531
If you're typing a key more than three times, you're using vim incorrectly

  No.20721

>>20718
>you're using a tool wrong because it's not how i use it
stop this meme

  No.20727

>>20718
Closing a block:

With tabs
>Hit Return to get to the next line
>delete the auto tab
>write the closing bracket
>carry on

With spaces:
>Return
>delete the four auto spaces (hit Backspace 4 times)
>etcetera

"The Vim way"
>Return
>Esc
>04di}
>carry on

You just choose to ignore what I actually meant.

  No.20728

>>20727
s/04d/04x/

  No.20734

>>20727
I'm not sure what trash editor you're using but both vim and emacs automatically de-indent when you write the closing bracket, and also automatically convert tabs to spaces. And if whatever reason you're using Python, you can press backspace and it deletes four spaces at a time so it's the same number of precious keystrokes as a tab.

  No.20738

I do

type func {
...
}

for functions I made, and I put the opening brace on the next line if it's something like the main function.

  No.20749

>>20718
Master programmers only use each key on the keyboard at most once.

  No.20752

I don't know why, but I tend to use different styles for C and C++, even if they're equivalent:
// C
void foo(int x)
{
if (bar(x)) {
return x;
} else {
return x*x;
}
}

// C++
void foo(int x)
{
if (bar(x))
{
return x;
}
else
{
return x*x;
}
}

Normally 4 spaces. I'm using 3 for a project I'm currently contributing to. It's not as bad as I first thought.

That's the 3rd time I've tried to reply, I must be really tired

  No.20753

>>20752
>void
Yeah I must be tired.

  No.20782

>>20417
too much Python in one's diet I suppose tbh

  No.20783

File: 1481735036486.png (76.98 KB, 183x200, Workspace 1_137.png)

>>20752
According to the highly regarded Steve McConnell, the first form is legitimate, but the second one violates a number of good engineering approaches (it's common use notwithstanding).

This would be legitimate though
if ( expression )
{
one-statement;
}

  No.20784

>>20783
forgot link to book resources
www.cc2e.com/page.aspx?hid=167

  No.20785

Im not sure people here are aware of why braces were even used in C instead of something like a end delimiter. Its because in original K&R C the local variables of a function were declared in between the parameter parenthesis and the function body within the braces. Here is some example code to illustrate this:
6585 bcopy (from, to, count)
int *from, *to;
{
register *a, *b, c;
a = from;
b = to;
c = count;
do
*b++ = *a++;
while (--cc);
}
This code was taken from Lion's Unix Commentary on page 18
http://www.lemis.com/grog/Documentation/Lions/book.pdf

  No.20798

>>20783
>>20785
At that point it's better to have FIOC like Python, or a way to structure programs that encourages indentation without requiring it, like MLs; the braces just become a waste of space.

  No.21078

>>20415
I just threw up in my mouth a little.

  No.21083

>>20783

The first example there doesn't look like Allman style, it looks like gnu style (or man-I-wish-I-was-writing-lisp-instead-of-C style).

Does anyone know of any non-gnu projects that use gnu style?