Live data from Hacker News

Ifs and &&s and Plan 9's Source Code

computationallyendowed.com

121–130 of 150 posts

Re: Ifs and &&s and Plan 9's Source Code

#122
post #77
post #11

Earlier quoted context omitted.

^ this is a detail which boggles my mind. why are our debuggers still line based? they're clearly not in every respect since you can basically always 'step in'to an && sub-expression, but nothing displays progress as you step through such things, nothing lets you put a breakpoint at some sub-expression, nearly every feature of every tool is delineated by lines as if they're the important part of a program.

Gdb for g++ may be; msvc for c# is not! Gdb usability and performance is a (THE) major shortcoming of the gnu tool chain.

[deleted]

Re: Ifs and &&s and Plan 9's Source Code

#123

Earlier quoted context omitted.

I believe that the layout of code is done by humans for humans. An auto code formatter destroys all of that meaning. I blogged about this more here: http://www.databasesandlife.com/do-not-use-automatic-code-re...

Yeah, I saw that. I think it's misguided. The amount of time spent on arguing about style far exceeds the time savings of the changes you propose. People can get used to different formats quite easily, but time spent arguing about and maintaining formats can never be recovered. Also, your formatter looks pretty brain-dead. clang-format formats all of those cases (in C++) as in your green examples with Google style tu…

"People can get used to different formats quite easily, but time spent arguing about and maintaining formats can never be recovered" This is nevertheless what this whole discussion is about :-) e.g. should one list those ifs straight like that, or use &&, etc.

"Also, your formatter looks pretty brain-dead", it is, alas, what Eclipse does, and that's pretty standard in the Java world, and it's also pretty standard to use its code formatter alas.

Re: Ifs and &&s and Plan 9's Source Code

#124
post #31

Oh god that code is fucking hideous. If someone who worked with me wrote that I'd talk to them about it and make sure they never did anything like that ever again. From the terrible argument names to the abuse of the single line if syntax (which should never be used anyway, always use curly braces.)

Makes me wonder what the quality of the architecture is on your projects is though. Not that I think coding style is unimportant, but it's all too easy to criticize yesteryear's code with today's style standards and totally miss the forest for the trees. Are you doing work that measures up to the ambition of Plan 9?

We all know how well that ambition turned out.

Re: Ifs and &&s and Plan 9's Source Code

#125
post #100

In Mathematica the FullForm of a && b is And[a, b]. You can use this to format long lists of conditions as And[ a, b ] You can also rely on the fact that logical expressions are always short-circuited, so False && Print["won't be printed"], doesn't print anything. Finally, you can put a bunch of conditions in a list and do And @@ list.

> You can also rely on the fact that logical expressions are always short-circuited, so False && Print["won't be printed"], doesn't print anything.

This is true for any language I can think of.

E.g. in perl

    open(my $fh, "
is idiomatic

Re: Ifs and &&s and Plan 9's Source Code

#126
post #47

Earlier quoted context omitted.

We can go deeper... if( b != nil && b->qid.type == a->qid.type && b->qid.path == a->qid.path && b->qid.vers == a->qid.vers && b->dev == a->dev && b->type == a->type ) { fprint(2, "cp: %s and %s are the same file\n", an, bn); ret = 1; } (Lined up the "a"s to make it obvious that they're all the same.)

I'd prefer some variation on: int samedirfile( Dir *a, Dir *b ) { if( a == b ) return 1; return ( a && b ) && ( a->qid.type == b->qid.type ) && ( a->qid.path == b->qid.path ) && ( a->qid.vers == b->qid.vers ) && ( a->dev == b->dev ) && ( a->type == b->type ); } ... if( samedirfile( a, b ) ) { fprint(2, "cp: %s and %s are the same file\n", an, bn); ret = 1; }

I'm so, so, so glad that new languages are banning braceless if/else bodies.

Re: Ifs and &&s and Plan 9's Source Code

#127
post #62
post #12

One downside to non-braced conditionals is that a semicolon accidentally placed after the conditional will cause the block to always run, e.g.: if (null != foo); bar(); This is valid code in C and Java, and bar() will always run in this case. Having seen people waste hours on such a semicolon, I always use braces, even in one-liners, because I never know when someone is going to break it out into multiple lines later…

I personally have never put a semicolon after a condition and being mainly a C# developer I have written a lot of them. Is this really something that happens more than once or twice in a lifetime?

Yes, but such mistake, once made, is very hard to notice (because you never do this, you don't look for it), so it may well lead to a fatal disaster. Hence 'once in a lifetime'.

Re: Ifs and &&s and Plan 9's Source Code

#129

Good luck using an auto formatter on a code base that uses this technique.

I believe that the layout of code is done by humans for humans. An auto code formatter destroys all of that meaning. I blogged about this more here: http://www.databasesandlife.com/do-not-use-automatic-code-re...

When working in a team, human code formatting can cost a lot of time. The rule is generally to have an auto code formatter that runs when we do a commit. The choice of formatting rules is made collectively and can be discussed. The usage of an auto formatting is generally mandated by society policies. I think it is a huge time saver (not using an auto formating tool is way to lose a lot of time).

Re: Ifs and &&s and Plan 9's Source Code

#130
post #9

When you use the fact that && is not the logical conjunction, you'd better use another if. if (b != nil) if (b->bla == a->bla) is so much clearer (and language agnostic) than if (b != nil && b->bla == a->bla)

Writing language-agnostic code is an incredible dangerous idea, since, of course, it is completely impossible. What does "->" mean in Ruby?
Post reply on HN