/developer|entrepreneur/i
Always looking for new developer talent, even those with zero experience, as you never know who's got the potential to become a great developer.
I'm a big proponent of trying to avoid "surprise if conditions", in other words a line that might, for reasons of not being shown in full in your code, not actually run like you think it does, but instead (surprise!) only run under certain conditions.
So things like this are fine:
returnifxreturnfalseunlessynextifz
Since you can see at a glance exactly what's going on there even if the conditions are fairly long.
That being said, a refactoring that fixes this up probably looks like this:
This is the "define and conditionally augment" approach to accumulating data in an object. The use of the case here makes it clear where to add any other cases should they arise.
I'm a big proponent of trying to avoid "surprise
if
conditions", in other words a line that might, for reasons of not being shown in full in your code, not actually run like you think it does, but instead (surprise!) only run under certain conditions.So things like this are fine:
Since you can see at a glance exactly what's going on there even if the conditions are fairly long.
That being said, a refactoring that fixes this up probably looks like this:
This is the "define and conditionally augment" approach to accumulating data in an object. The use of the
case
here makes it clear where to add any other cases should they arise.Not a bad idea, thanks for sharing! Personally never liked cases but this might be a good use for them.