Re: LLVM Coding Standards
On 04/15/2011 01:10 PM, Spacen Jasset wrote: As other posters have pointed out, it seems to me, at least, that having a way to express your model/idea or view of a problem directly is the most useful thing a language can give you. This is my definition of a good language :-) Denis -- _ vita es estrany spir.wikidot.com
Re: LLVM Coding Standards
On 12/04/2011 11:21, Mafi wrote:
Am 12.04.2011 00:31, schrieb Spacen Jasset:
std::getline(is, line);
while (line.size() != 0)
{
...some things...
std::getline(is, line);
}
What's wrong with
while( std::getline(is, line), (line.size() != 0) ) {
//... some things
}
I mean, that's what the comma operator is for.
Ah yes well. I was wondering who was going to throw that in.
Well...okay. But sometimes it's not just one statement that you always
need to do before your test condition.
Also, I would say that sort of code is a little bit more difficult to
read. I don't mind typing a little bit more to be able to make it look a
bit better.
As other posters have pointed out, it seems to me, at least, that having
a way to express your model/idea or view of a problem directly is the
most useful thing a language can give you.
In other words less code structure design caused by safety and/or other
issues, and more problem, higher level design visible in the code. As an
example, perhaps not a great one. The RAII pattern. It's a code type of
design/solution used to manage resources, and specifically to prevent
resource leaks, rather than anything in particular to do with a problem
that is being solved. e.g. That of reading and processing a file.
So we end up with
(a) solution to some problem
(b) solution to the method of expressing the solution to the problem
as you have put above:
while( std::getline(is, line), (line.size() != 0) ) {
There is a strong component of (b), rather than just (a), which ideally
in utopia we don't want to spend time on thinking about.
Re: LLVM Coding Standards
Hi, about early breaks/returns, it seems that might answer to a similar question is widely aproved, some maybe it's of interest : http://programmers.stackexchange.com/questions/58237/are-break-and-continue-bad-programming-practices/58253#58253 (about early breaks/return/continue) "When used at the start of a block, as first checks made, they act like preconditions, so it's good. When used in the middle of the block, with some code around, they act like hidden traps, so it's bad." The other answers and commetns are interesting to read too. Anyway I think it's offtopic and such discussion could be done on another more appropriate mailing list or website. Klaim - Joël Lamotte.
Re: LLVM Coding Standards
"spir" wrote in message news:mailman.3428.1302601845.4748.digitalmar...@puremagic.com... > On 04/11/2011 09:58 PM, spir wrote: >> I'm reading (just for interest) the LLVM Coding Standards at >> http://llvm.org/docs/CodingStandards.html. Find them very interesting >> because >> their purposes are clearly explained. Below sample. > > I also love their note about naming: > > > Name Types, Functions, Variables, and Enumerators Properly > > Poorly-chosen names can mislead the reader and cause bugs. We cannot > stress enough how important it is to use descriptive names. Pick names > that match the semantics and role of the underlying entities, within > reason. Avoid abbreviations unless they are well known. After picking a > good name, make sure to use consistent capitalization for the name, as > inconsistency requires clients to either memorize the APIs or to look it > up to find the exact spelling. > > I might have mentioned this before, but there was one company I used to work for that regularly had index/counter variables with names like "aaa", "bbb" and "ccc", and I even found a data-loading function named "save". That confused the crap out of me for a quite a while. I don't think I'll ever forget that. There were sooo many other code WTFs there too. Perhaps unsurprisingly, it was a VB house.
Re: LLVM Coding Standards
"Mafi" wrote in message
news:io19ar$47h$1...@digitalmars.com...
> Am 12.04.2011 00:31, schrieb Spacen Jasset:
>> std::getline(is, line);
>> while (line.size() != 0)
>> {
>> ...some things...
>> std::getline(is, line);
>> }
>
> What's wrong with
> while( std::getline(is, line), (line.size() != 0) ) {
> //... some things
> }
>
> I mean, that's what the comma operator is for.
I'm deathly afraid of the comma operator.
Re: LLVM Coding Standards
Am 12.04.2011 00:31, schrieb Spacen Jasset:
std::getline(is, line);
while (line.size() != 0)
{
...some things...
std::getline(is, line);
}
What's wrong with
while( std::getline(is, line), (line.size() != 0) ) {
//... some things
}
I mean, that's what the comma operator is for.
Re: LLVM Coding Standards
On 04/12/2011 03:15 AM, Daniel Gibson wrote:
While I am on the subject, I've *always* thought major languages have
> poor loop constructs:
>
>
> (A)
>
> for (;;)
> {
> std::getline(is, line);
> if (line.size() == 0)
> break;
> ...some things...
> }
>
(...)
>
> Instead you could just have:
>
> loop
> {
>...
>if (condition) exit;
>...
> }
>
> instead of WHILE and DO. Whereby you *must* have an exit condition.
>
>
> But I suppose you need a FOR loop because the following may be error prone.
>
> int x=0;
> loop
> {
> if x> 9 exit;
> ...
> x++;
> }
Yeah. And I guess while-loops also have their uses.
I think just loop like you're suggesting is not available because
for(;;) and while(1) achieve the same thing without too much additional
typing.
I've been thinking of a loop construct allowing either while or until, each
either at start or end, or even both:
loop [(while|until) condition] {
body
} [(while|until) condition]
Side-Note: I favor until over while because I "feel" (for what reason?)
booleans should be initially false, or false by default, thus the end-condition
should express a change and be positive.
loop until end1 {
body
} until end2
ends are initially false
loop while end1 {
body
} while end2
ends are initially true
Denis
--
_
vita es estrany
spir.wikidot.com
Re: LLVM Coding Standards
On 04/12/2011 03:08 AM, Walter Bright wrote: On 4/11/2011 2:03 PM, bearophile wrote: it's very far from the C-style hairy code of DMD I'm overcompensating for being bald. Unfortunately, beeing bald does not seem to always help. While I'm nearly bald as well, I found the few pieces of dmd and core stdlib I've tried to understand rather difficult. But not that much because of coding style than for not beeing able to really grok the *design*. Maybe a few more comments oriented toward overall conception would help; provided they're not overly hairy themselves; dunno. Denis -- _ vita es estrany spir.wikidot.com
Re: LLVM Coding Standards
On 04/12/2011 02:34 AM, Nick Sabalausky wrote: The last few years though, I've been finding that I *never* have any trouble grokking code due to early exits or continue (unless the code is already convoluted anyway). And I've also realized I find code that makes intelligent use of it to be much *easier* to understand and reason about since it takes the otherwise-distracting special cases and just shoves them out of the way so the rest of the code can focus on the real core of the task. This is imo a very good explanation. Denis -- _ vita es estrany spir.wikidot.com
Re: LLVM Coding Standards
On 04/12/2011 12:31 AM, Spacen Jasset wrote: I think that people like to follow rules, that is as soon as they have internalised them and made them their own. What this means is that they often then follow them to a fault, and you get deeply nested, but "structured" code, where instead you would be better of with more logically linear code as in the case of the early exit. Coding standards should probably just say: try and write readable code. Yes! Everyone knows what readable code looks like. No! It's a cultural issue. In C and C-derived languages, culture favors cleverness, complication, & terseness over readability. (Actually, even when readable code code is terser.) The key issue is readable code looks *easier*, thus it's not that rewarding. Just like what a dancer truelly masters (read: with grace) *looks* easy to do. Readabilty, like simplicity, is *very* difficult to achieve. Designing a language that favors readability (and/or simplicity) as well; among other points, it requires allowing users express their models by direct analogy (I mean the code should somehow mirror the model, its contents & structure, like a homomorphism or a metaphor). Denis -- _ vita es estrany spir.wikidot.com
Re: LLVM Coding Standards
On 04/11/2011 09:58 PM, spir wrote: I'm reading (just for interest) the LLVM Coding Standards at http://llvm.org/docs/CodingStandards.html. Find them very interesting because their purposes are clearly explained. Below sample. I also love their note about naming: Name Types, Functions, Variables, and Enumerators Properly Poorly-chosen names can mislead the reader and cause bugs. We cannot stress enough how important it is to use descriptive names. Pick names that match the semantics and role of the underlying entities, within reason. Avoid abbreviations unless they are well known. After picking a good name, make sure to use consistent capitalization for the name, as inconsistency requires clients to either memorize the APIs or to look it up to find the exact spelling. Dunno who the author is, anyway this text is great. I even appreciate points I totally disagree with, because their *purpose* is properly xplained & argumented: thus, discussion can nicely follow on good bases. It looks like if one can logically show them where & why they are wrong, they will actually change their mind (a rare event in disussions among programmers, esp. about coding guidelines ;-). Denis -- _ vita es estrany spir.wikidot.com
Re: LLVM Coding Standards
On 12.04.2011 2:31, Spacen Jasset wrote:
On 11/04/2011 20:58, spir wrote:
[slightly OT]
Hello,
I'm reading (just for interest) the LLVM Coding Standards at
http://llvm.org/docs/CodingStandards.html. Find them very interesting
because their purposes are clearly explained. Below sample.
Denis
[snip]
Instead you could just have:
loop
{
...
if (condition) exit;
...
}
instead of WHILE and DO. Whereby you *must* have an exit condition.
But I suppose you need a FOR loop because the following may be error
prone.
int x=0;
loop
{
if x > 9 exit;
x++;
}
Looks a lot like PL/SQL;)
So you would then end up with a LOOP a FOREVER (perhaps which is
for(;;) by convention anyway) and a FOR loop.
I'll put the coffee down now...
--
Dmitry Olshansky
Re: LLVM Coding Standards
On 2011-04-11 21:58, spir wrote: [slightly OT] Hello, I'm reading (just for interest) the LLVM Coding Standards at http://llvm.org/docs/CodingStandards.html. Find them very interesting because their purposes are clearly explained. Below sample. Denis === sample === Use Early Exits and continue to Simplify Code I usually try to use early exists as much as possible. I think it simplifies the code. -- /Jacob Carlborg
Re: LLVM Coding Standards
Spacen Jasset wrote:
While I am on the subject, I've *always* thought major languages have
poor loop constructs:
(A)
for (;;)
{
std::getline(is, line);
if (line.size() == 0)
break;
...some things...
}
You have to call getline always at least once, then you need to test if
the line is empty to terminate the loop. So how do you do it another way?
FORTH had BEGIN ... WHILE ... REPEAT. I really miss it.
C family languages just have do ... while, which seems to be pretty much
useless.
Re: LLVM Coding Standards
Walter: > I'm overcompensating for being bald. *hands a Code Brush [TM]* :-) Bye, bearophile
Re: LLVM Coding Standards
Am 12.04.2011 00:31, schrieb Spacen Jasset:
> On 11/04/2011 20:58, spir wrote:
>> [slightly OT]
>>
>> Hello,
>>
>> I'm reading (just for interest) the LLVM Coding Standards at
>> http://llvm.org/docs/CodingStandards.html. Find them very interesting
>> because their purposes are clearly explained. Below sample.
>>
>> Denis
>>
>
> That seem all fairly sensible. It also reminds me of open source
> projects written in C, where GOTO is used, like so:
>
>
> HANDLE handle1 = open(...);
>
> ...
> if (out_of_memory)
> goto cleanup;
>
> if (invalid_format)
> goto cleanup;
> ...
>
> cleanup:
>if (handle1)
> close(handle1);
>if (handle2)
> close(handle2);
>
>
> This code uses the dreaded goto statement, but I belive you can see that
> the author is trying to make the code more readable, or at least get rid
> of the nested indents/multiple cleanup problem you inevitably come
> across at some points in C code. It does tend to be more readable than
> the alternative, too.
>
I agree. I've seen and used this in C code as well.
IMHO it is mostly a workaround for not having exceptions in C - the
cleanup-stuff would belong in catch{...} or finally{...} (or even
better, when scope-guards are available, in scope(exit){...} or
scope(failure){...}
And I agree that this is far more readable than using a plethora of bool
flags and ifs.
> I think that people like to follow rules, that is as soon as they have
> internalised them and made them their own. What this means is that they
> often then follow them to a fault, and you get deeply nested, but
> "structured" code, where instead you would be better of with more
> logically linear code as in the case of the early exit. Coding standards
> should probably just say: try and write readable code. Everyone knows
> what readable code looks like. It just not always quick or easy to make
> it that way.
>
>
> While I am on the subject, I've *always* thought major languages have
> poor loop constructs:
>
>
> (A)
>
> for (;;)
> {
> std::getline(is, line);
> if (line.size() == 0)
> break;
> ...some things...
> }
>
(...)
>
> Instead you could just have:
>
> loop
> {
> ...
> if (condition) exit;
> ...
> }
>
> instead of WHILE and DO. Whereby you *must* have an exit condition.
>
>
> But I suppose you need a FOR loop because the following may be error prone.
>
> int x=0;
> loop
> {
> if x > 9 exit;
> ...
> x++;
> }
Yeah. And I guess while-loops also have their uses.
I think just loop like you're suggesting is not available because
for(;;) and while(1) achieve the same thing without too much additional
typing.
Cheers,
- Daniel
Re: LLVM Coding Standards
"Walter Bright" wrote in message news:io08sr$ouq$1...@digitalmars.com... > On 4/11/2011 2:03 PM, bearophile wrote: >> it's very far from the C-style hairy code of DMD > > I'm overcompensating for being bald. Heh. Now that's a classic line if I've ever heard one :)
Re: LLVM Coding Standards
"Spacen Jasset" wrote in message
news:invvmu$7ha$1...@digitalmars.com...
>
> That seem all fairly sensible. It also reminds me of open source projects
> written in C, where GOTO is used, like so:
>
>
> HANDLE handle1 = open(...);
>
> ...
> if (out_of_memory)
> goto cleanup;
>
> if (invalid_format)
> goto cleanup;
> ...
>
> cleanup:
>if (handle1)
> close(handle1);
>if (handle2)
> close(handle2);
>
>
> This code uses the dreaded goto statement, but I belive you can see that
> the author is trying to make the code more readable, or at least get rid
> of the nested indents/multiple cleanup problem you inevitably come across
> at some points in C code. It does tend to be more readable than the
> alternative, too.
>
I'm a big anti-goto guy, but I think what bugs me about that code more than
the goto is that its particular style of error handling gives me flashbacks
of VB6. Bring on the try/catch/finally and scope guards!
Of course, I do agree, without try/catch/finally or scope guards that code
really isn't too bad of an alternative.
> I think that people like to follow rules, that is as soon as they have
> internalised them and made them their own. What this means is that they
> often then follow them to a fault, and you get deeply nested, but
> "structured" code, where instead you would be better of with more
> logically linear code as in the case of the early exit. Coding standards
> should probably just say: try and write readable code. Everyone knows what
> readable code looks like. It just not always quick or easy to make it that
> way.
>
I think that's a good analysis. And particularly true of programmers. We're
trained to think in terms of defining structure and following it. We're more
like Hermes from Futurama than most of us might think. Minus the dreadlocks,
of course (which incidentally look terrible in real life, unlike on TV. In
real life they just look like someone forgot to wash their hair for twenty
years.)
>
> While I am on the subject, I've *always* thought major languages have poor
> loop constructs:
>
>
[..snip..]
>
> Instead you could just have:
>
> loop
> {
> ...
> if (condition) exit;
> ...
> }
>
> instead of WHILE and DO. Whereby you *must* have an exit condition.
>
Yea, once in a while I do come across a need to have the exit condition in
the middle of the loop body. It doesn't happen to me often, but it is kind
of annoying when it does crop up. I feel like I have to contort the task to
fit the tool. Fortunately, though, like I said, I don't come across such
cases often. YMMV, of course.
> I'll put the coffee down now...
>
[OT]: My local World Market has a "Vanilla Macadamia Kona Coffee". A little
pricey as far as coffees go, but I think it's becoming my new god. :) If
only I could find it in whole-bean decaf form... (I don't like the way
caffeine affects me, and pre-ground doesn't store well unless you have an
air-tight container on hand.) It's kind of weird if you think about it how
much our society has gone nuts over what's essentially "bean juice" -
doesn't sound so appetizing when you describe it that way :) Um, ok, yea I
guess I *really* need decaf, don't I? ;)
Re: LLVM Coding Standards
On 4/11/2011 2:03 PM, bearophile wrote: it's very far from the C-style hairy code of DMD I'm overcompensating for being bald.
Re: LLVM Coding Standards
"Andrei Alexandrescu" wrote in message news:invnce$2mfr$4...@digitalmars.com... > On 4/11/11 2:58 PM, spir wrote: >> [slightly OT] >> >> Hello, >> >> I'm reading (just for interest) the LLVM Coding Standards at >> http://llvm.org/docs/CodingStandards.html. Find them very interesting >> because their purposes are clearly explained. Below sample. >> >> Denis >> >> === sample === >> Use Early Exits and continue to Simplify Code > > Heh heh heh. This is bound to annoy many a dinosaur. And they even didn't > need to pull the exceptions argument! > That's something I've come full circle on. I stared out on the old interactive BASICs (the ones with line numbers and gratuitous GOTO). So I didn't originally have a problem with early exits and continue even after I had moved to C/C++ (and started agreeing, from direct experience, with "goto is evil" - which I still agree with). Then in the "OO-is-your-God" age of the late 90's and early 2000's I found some reasonable sounding arguments for avoiding early exits and continue and got very much into the habit of avoiding them. The last few years though, I've been finding that I *never* have any trouble grokking code due to early exits or continue (unless the code is already convoluted anyway). And I've also realized I find code that makes intelligent use of it to be much *easier* to understand and reason about since it takes the otherwise-distracting special cases and just shoves them out of the way so the rest of the code can focus on the real core of the task. Plus, Andrei is right: Reducing the number of nested scopes makes a big improvement in readability. I've often been considered a dinosaur, and probably for good reason. But consider this to be one early-exit-and-continue-loving dino. :)
Re: LLVM Coding Standards
On 11/04/2011 20:58, spir wrote:
[slightly OT]
Hello,
I'm reading (just for interest) the LLVM Coding Standards at
http://llvm.org/docs/CodingStandards.html. Find them very interesting
because their purposes are clearly explained. Below sample.
Denis
That seem all fairly sensible. It also reminds me of open source
projects written in C, where GOTO is used, like so:
HANDLE handle1 = open(...);
...
if (out_of_memory)
goto cleanup;
if (invalid_format)
goto cleanup;
...
cleanup:
if (handle1)
close(handle1);
if (handle2)
close(handle2);
This code uses the dreaded goto statement, but I belive you can see that
the author is trying to make the code more readable, or at least get rid
of the nested indents/multiple cleanup problem you inevitably come
across at some points in C code. It does tend to be more readable than
the alternative, too.
I think that people like to follow rules, that is as soon as they have
internalised them and made them their own. What this means is that they
often then follow them to a fault, and you get deeply nested, but
"structured" code, where instead you would be better of with more
logically linear code as in the case of the early exit. Coding standards
should probably just say: try and write readable code. Everyone knows
what readable code looks like. It just not always quick or easy to make
it that way.
While I am on the subject, I've *always* thought major languages have
poor loop constructs:
(A)
for (;;)
{
std::getline(is, line);
if (line.size() == 0)
break;
...some things...
}
You have to call getline always at least once, then you need to test if
the line is empty to terminate the loop. So how do you do it another way?
(B)
std::getline(is, line);
while (line.size() != 0)
{
...some things...
std::getline(is, line);
}
Isn't there something a bit wrong here? N.B. a do .. while doesn't help
here either.
in (A) there is no duplication, in essence what I am saying, is that
there should be a loop whereby you can put the exit condition where you
need it, but *also* the compiler should check you have an exit condition
to prevent mistakes. This whole WHILE vs DO vs FOR loops thing is
strange to me.
Instead you could just have:
loop
{
...
if (condition) exit;
...
}
instead of WHILE and DO. Whereby you *must* have an exit condition.
But I suppose you need a FOR loop because the following may be error prone.
int x=0;
loop
{
if x > 9 exit;
...
x++;
}
So you would then end up with a LOOP a FOREVER (perhaps which is for(;;)
by convention anyway) and a FOR loop.
I'll put the coffee down now...
Re: LLVM Coding Standards
Andrei: > Heh heh heh. This is bound to annoy many a dinosaur. And they even > didn't need to pull the exceptions argument! I find the LLVM C++ source code readable and sometimes even elegant for being C++ (it's very far from the C-style hairy code of DMD, despite sometimes DMD is a little more efficient during compilation). So I think they are doing a good job. If the source code of an open source project isn't well readable, new people will have less desire to work on the code to add features, remove bugs, etc. CPython developers keep the C source code very simple and very readable even if sometimes this forces to use a bit less efficient code. Bye, bearophile
Re: LLVM Coding Standards
== Quote from spir (denis.s...@gmail.com)'s article
> [slightly OT]
> Hello,
> I'm reading (just for interest) the LLVM Coding Standards at
> http://llvm.org/docs/CodingStandards.html. Find them very interesting because
> their purposes are clearly explained. Below sample.
> Denis
> === sample ===
> Use Early Exits and continue to Simplify Code
> When reading code, keep in mind how much state and how many previous decisions
> have to be remembered by the reader to understand a block of code. Aim to
> reduce indentation where possible when it doesn't make it more difficult to
> understand the code. One great way to do this is by making use of early exits
> and the continue keyword in long loops. As an example of using an early exit
> from a function, consider this "bad" code:
> Value *DoSomething(Instruction *I) {
>if (!isa(I) &&
>I->hasOneUse() && SomeOtherThing(I)) {
> ... some long code
>}
>return 0;
> }
> This code has several problems if the body of the 'if' is large. When you're
> looking at the top of the function, it isn't immediately clear that this only
> does interesting things with non-terminator instructions, and only applies to
> things with the other predicates. Second, it is relatively difficult to
> describe (in comments) why these predicates are important because the if
> statement makes it difficult to lay out the comments. Third, when you're deep
> within the body of the code, it is indented an extra level. Finally, when
> reading the top of the function, it isn't clear what the result is if the
> predicate isn't true; you have to read to the end of the function to know that
> it returns null.
> It is much preferred to format the code like this:
> Value *DoSomething(Instruction *I) {
>// Terminators never need 'something' done to them because ...
>if (isa(I))
> return 0;
>// We conservatively avoid transforming instructions with multiple uses
>// because goats like cheese.
>if (!I->hasOneUse())
> return 0;
>// This is really just here for example.
>if (!SomeOtherThing(I))
> return 0;
>... some long code
> }
I've been doing similar such shuffles in the GDC code recently. One example that
gets my dander right up:
if (SomeOtherThing(I))
{
... some long code
}
else
I->SomeValue = t;
Re: LLVM Coding Standards
On 4/11/11 2:58 PM, spir wrote: [slightly OT] Hello, I'm reading (just for interest) the LLVM Coding Standards at http://llvm.org/docs/CodingStandards.html. Find them very interesting because their purposes are clearly explained. Below sample. Denis === sample === Use Early Exits and continue to Simplify Code Heh heh heh. This is bound to annoy many a dinosaur. And they even didn't need to pull the exceptions argument! Andrei
LLVM Coding Standards
[slightly OT]
Hello,
I'm reading (just for interest) the LLVM Coding Standards at
http://llvm.org/docs/CodingStandards.html. Find them very interesting because
their purposes are clearly explained. Below sample.
Denis
=== sample ===
Use Early Exits and continue to Simplify Code
When reading code, keep in mind how much state and how many previous decisions
have to be remembered by the reader to understand a block of code. Aim to
reduce indentation where possible when it doesn't make it more difficult to
understand the code. One great way to do this is by making use of early exits
and the continue keyword in long loops. As an example of using an early exit
from a function, consider this "bad" code:
Value *DoSomething(Instruction *I) {
if (!isa(I) &&
I->hasOneUse() && SomeOtherThing(I)) {
... some long code
}
return 0;
}
This code has several problems if the body of the 'if' is large. When you're
looking at the top of the function, it isn't immediately clear that this only
does interesting things with non-terminator instructions, and only applies to
things with the other predicates. Second, it is relatively difficult to
describe (in comments) why these predicates are important because the if
statement makes it difficult to lay out the comments. Third, when you're deep
within the body of the code, it is indented an extra level. Finally, when
reading the top of the function, it isn't clear what the result is if the
predicate isn't true; you have to read to the end of the function to know that
it returns null.
It is much preferred to format the code like this:
Value *DoSomething(Instruction *I) {
// Terminators never need 'something' done to them because ...
if (isa(I))
return 0;
// We conservatively avoid transforming instructions with multiple uses
// because goats like cheese.
if (!I->hasOneUse())
return 0;
// This is really just here for example.
if (!SomeOtherThing(I))
return 0;
... some long code
}
This fixes these problems. A similar problem frequently happens in for loops. A
silly example is something like this:
for (BasicBlock::iterator II = BB->begin(), E = BB->end(); II != E; ++II) {
if (BinaryOperator *BO = dyn_cast(II)) {
Value *LHS = BO->getOperand(0);
Value *RHS = BO->getOperand(1);
if (LHS != RHS) {
...
}
}
}
When you have very, very small loops, this sort of structure is fine. But if it
exceeds more than 10-15 lines, it becomes difficult for people to read and
understand at a glance. The problem with this sort of code is that it gets very
nested very quickly. Meaning that the reader of the code has to keep a lot of
context in their brain to remember what is going immediately on in the loop,
because they don't know if/when the if conditions will have elses etc. It is
strongly preferred to structure the loop like this:
for (BasicBlock::iterator II = BB->begin(), E = BB->end(); II != E; ++II) {
BinaryOperator *BO = dyn_cast(II);
if (!BO) continue;
Value *LHS = BO->getOperand(0);
Value *RHS = BO->getOperand(1);
if (LHS == RHS) continue;
...
}
This has all the benefits of using early exits for functions: it reduces
nesting of the loop, it makes it easier to describe why the conditions are
true, and it makes it obvious to the reader that there is no else coming up
that they have to push context into their brain for. If a loop is large, this
can be a big understandability win.
--
_
vita es estrany
spir.wikidot.com
