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.
[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?
Just my 2 cents.
>
> Andrew
>
--
github.com/KingCrunch
