Morning Nikita,
It is actually the first kind I'm rebelling against.
I think the second kind might lead people to think we would accept the
first kind, and I think an extreme version of the second kind could also
harm readability.
How about we adopt the rule of thumb that "declarations should be grouped
for clarity" (as sort of suggested by you)
This means you can write the kind of code you want to write, and I can
refuse to merge the kind of code I don't want to merge ?
Cheers
Joe
On Sat, Nov 12, 2016 at 1:59 PM, Nikita Popov <nikita....@gmail.com> wrote:
> On Sat, Nov 12, 2016 at 2:21 PM, Joe Watkins <pthre...@pthreads.org>
> wrote:
>
>> Morning Nikita,
>>
>> All good points, that it's hard to refute.
>>
>> However, right now, I know where all variables that are going to be used
>> are declared, no matter the size of the function or it's complexity. If not
>> at the very top, eyes get good at scanning for blocks.
>>
>> What I don't want is to have to scan already complicated code to find out
>> when a variable was declared.
>>
>> We need to have rules of thumb, and unless someone can defend their use
>> rigorously, I would say the rule of thumb that code shouldn't be mixi ought
>> to be followed. At least it ought to be followed in the top layer of PHP
>> (anything inside a PHP|ZEND_FUNCTION and such).
>>
>> A defence of elegance is legitimate, so long as their use does genuinely
>> increase elegance. Such examples exist, but I think more examples of mixi
>> code being harder to follow exist ...
>>
>> Cheers
>> Joe
>>
>
> I have the feeling that we both sort-of agree, but are really talking
> about different things.
>
> There are two ways in which you can have code mixed with declarations. The
> first one is within a single "basic block", like this:
>
> int a = ...;
> b = ...;
> int c = ...;
> a = ...;
> float d = ...;
> // ...
>
> I can totally see how some many people might find this kind of code to be
> objectionable.
>
> However, the use-case that I have in mind is different -- it's the case
> where declarations **are** at the top of a block -- but its the top of a
> basic block in terms of control flow, not a block in terms of C syntax. To
> clarify what I mean by that: For a compiler (and arguably, a programmer),
> the control flow of
>
> if (...) {
> return;
> }
>
> // Basic block starts here, but not C block
> type var = ...;
>
> and of
>
> if (...) {
> return;
> } else {
> // Basic block starts here, and C block
> type var = ...;
> }
>
> is the same. The declaration in both cases is at the top of a control-flow
> block. It just doesn't happen to coincide with a syntactic C block.
>
> This is the case I'm interested in.
>
> Anyway, I'll just leave this gem from our codebase here:
> https://github.com/php/php-src/blob/master/ext/standard/
> http_fopen_wrapper.c#L114 (Some of those variables have 500 lines of code
> between declaration and first use)
>
> Thanks,
> Nikita
>
