| 1 |
On Wed, Nov 30, 2016 at 7:11 AM, konsolebox <konsolebox@×××××.com> wrote: |
| 2 |
>>> I also prefer some things this way: |
| 3 |
>>> |
| 4 |
>>> - Indent the contents of the first `if` block for consistency's sake, |
| 5 |
>>> and less confusion. |
| 6 |
>> |
| 7 |
>> I disagree; indenting the entire eclass is silly and does not really |
| 8 |
>> improve readability. Also, this is a very common pattern found in |
| 9 |
>> other eclasses. |
| 10 |
> |
| 11 |
> I prefer following consistency before anything else. And it's just |
| 12 |
> uncommon and odd, but it's not silly. Imagine if you use another `if` |
| 13 |
> block on the second level where more functions are defined. Would you |
| 14 |
> also not indent that? |
| 15 |
|
| 16 |
That first "if" is a bit of a special case; it's only there to prevent |
| 17 |
the code from being executed more than once in global scope. This |
| 18 |
provides a minor speed boost when the eclass gets sourced more than |
| 19 |
once, and makes sure that any global variables are only set once. |
| 20 |
|
| 21 |
I think of it as being similar to pre-processor statement you would |
| 22 |
find in a C header file; one does not generally indent all the code |
| 23 |
within a C header file, because it just introduces a big chunk of |
| 24 |
whitespace that does not improve code readability. |
Archives