On Sat, Nov 17, 2012 at 4:13 PM, Sebastian Krebs <krebs.seb@xxxxxxxxx> wrote:
> 2012/11/17 Andrew Ballard <aballard@xxxxxxxxx>
>
>> On Nov 16, 2012 10:24 PM, "tamouse mailing lists" <tamouse.lists@xxxxxxxxx>
>> wrote:
>> >
>> > On Fri, Nov 16, 2012 at 12:41 PM, Sebastian Krebs <krebs.seb@xxxxxxxxx>
>> wrote:
>> > > Beside this it can be rewritten as
>> > >
>> > > switch ((int) (($count-1) / 7) {
>> > > case 0: // 1-7
>> > > case 1: // 8 - 14
>> > > default: // above 15
>> > > }
>> >
>> > Nice code refactoring :) Just a tad obscure for someone coming along
>> > later
>>
>> Not only obscure, but depending on the rule being processed could be plain
>> wrong. It works for the values shown so far, but what if another test is
>> added to the use case in the future that doesn't fit the clever solution?
>>
> Like so often in our developers world many things breaks, when it comes to
> new requirements.
>
>> Without knowing the intent of the code, it could be a headache to maintain.
>>
> Interesting, that you see 5 lines of code and assume, that nobody will ever
> get the intent of this code ;) Of course the context is missing. I guess,
> that "$count" is something like "remaining days", or such, because "7" and
> "14" look like "one week" and "two weeks", respectively. Thus I wouldn't
> name the variable "$count" [1], but "$remainingDays" and voila: Context is
> back and so is the intent :)
>
> Of course the above code has a quite limited use-case, but that was the
> requirement (for now, see KISS). If you need more, refactor/rewrite it.
That's precisely my point. If the solution you posted, complete with
your assumptions about the significance of the values "7" and "14",
matches the requirements then use it. If your assumptions were wrong,
and a future revision may potentially require special handling for
certain values like "3" or "8" that cannot be evaluated using your
equation, then the whole block may have to be refactored rather than
simply adding a couple lines for the case. In the spirit of "keeping
it simple," I would prefer the code that requires less refactoring.
I'm not assuming that "nobody will ever get the [coder's] intent" of a
segment of code at all. It's not so much about what the code does, as
WHY it is doing it.
> [1] Even further: I was taught, that if I ever want to name a variable like
> "count", "status", "type", ... I should stop and probably don't use this
> name. In most cases they are used wrong. This example here is quite good:
> "$count" what?
It depends. Generally I agree with you, but if it is a simple loop
counter in a small block of code where variable scope issues and
overall readability of the code is not diminished I'm fine with names
like $count or $n.
Andrew
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
