I think I'd go with this option too, unless the fast path was something very
simple like...
If (NULL == parameter) return NULL_POINTER_ERROR;
That way you don't have to have all the code below indented for this simple
case.
Stu.
2009/6/8 Vic
>
> >Assume that the fast path is a single exp
On Mon, Jun 08 at 03:41, Andy Random wrote:
...
> I hope that "other programmer" isn't Kelly?
Nope she's the "junior" still on probation. I could tell her to
mend her ways :)
--
Bob Dunlop
--
Please post to: Hampshire@mailman.lug.org.uk
Web Interface: https://mailman.lug.org.uk/mailma
On Mon, 8 Jun 2009, Bob Dunlop wrote:
> So I guess you wouldn't be a fan of the GNU C construct
>
>something ?: fallback
>
> equivalent of standard C
>
>something ? something : fallback
>
> providing something has no side effects. No significant advantage that I
> can see and a real port
Hugo Mills wrote:
>Yet one more reason to avoid ternary operators... (If you haven't
> guessed yet, I'm not a fan of the whole concept. I've rarely met a use
> of the ternary operator, in any language, that made code easier to
> read.)
>
>Hugo.
>
I use the following fairly regularly when
Hugo Mills wrote:
> On Mon, Jun 08, 2009 at 03:09:49PM +0100, Vic wrote:
>
>> #define min(a, b) ((a>
>I'll live with this use. Concise, readable (once), and above all
> hidden from view at the point of use.
>
Until someone does
min (a++, b++)
and wonders why it
2009/6/8 Hugo Mills :
> On Mon, Jun 08, 2009 at 03:50:47PM +, Isaac Close wrote:
>> --- On Mon, 8/6/09, Hugo Mills wrote:
>> > > On Mon, Jun 08, 2009 at 02:53:12PM +0100, Daniel Pope wrote:
>> > >
>> > > result = 1 if test() else -1
>> > >
>> > > the idea being that the difference in syntax st
On Mon, Jun 08, 2009 at 03:50:47PM +, Isaac Close wrote:
> --- On Mon, 8/6/09, Hugo Mills wrote:
> > > On Mon, Jun 08, 2009 at 02:53:12PM +0100, Daniel Pope wrote:
> > >
> > > result = 1 if test() else -1
> > >
> > > the idea being that the difference in syntax stresses
> > the success path
--- On Mon, 8/6/09, Hugo Mills wrote:
> > On Mon, Jun 08, 2009 at 02:53:12PM +0100, Daniel Pope wrote:
> >
> > result = 1 if test() else -1
> >
> > the idea being that the difference in syntax stresses
> the success path
> > as the default with the failure path as a fallback.
>
> Eww. That
> > > I'm not a fan of the whole concept. I've rarely met a use
> > > of the ternary operator, in any language, that made code easier to
> > > read.)
>
I'd better not reveal some of my code then ;-) I have been known to hang
ternaries inside me ternaries on occasion. A quick scan for \?.*: finds o
Hugo Mills wrote:
>> result = 1 if test() else -1
>>
>> the idea being that the difference in syntax stresses the success path
>> as the default with the failure path as a fallback.
>
> Eww. That's *intensely* ugly.
I felt the same way the first time I saw it, but actually encountering
it it'
On Mon, Jun 08, 2009 at 03:09:49PM +0100, Vic wrote:
>
> > I'm not a fan of the whole concept. I've rarely met a use
> > of the ternary operator, in any language, that made code easier to
> > read.)
>
> They can be very useful :
>
> ArrayStart = StartsWithZero ? 0 : 1 ;
>
> Or even :
>
> #defi
Hi,
On Mon, Jun 08 at 02:57, Hugo Mills wrote:
...
>Yet one more reason to avoid ternary operators... (If you haven't
> guessed yet, I'm not a fan of the whole concept. I've rarely met a use
> of the ternary operator, in any language, that made code easier to
> read.)
So I guess you wouldn't
> I'm not a fan of the whole concept. I've rarely met a use
> of the ternary operator, in any language, that made code easier to
> read.)
They can be very useful :
ArrayStart = StartsWithZero ? 0 : 1 ;
Or even :
#define min(a, b) ((ahttps://mailman.lug.org.uk/mailman/listinfo/hampshire
LUG URL
Vic wrote:
> Style A has multiple returns from the function. That's one of those things
> that's just fine right up until it isn't; code grows as different people
> work on it, and sooner or later, you can't see both returns on the same
> page. That's when mistakes happen.
Totally disagree with th
On Mon, Jun 08, 2009 at 02:53:12PM +0100, Daniel Pope wrote:
> Hugo Mills wrote:
> > I happily thought that the ternary operator had been put to death
> > in Python, until I saw this little gem in some code yesterday:
> >
> > (is_forward and "F" or "B")
> >
> > The perpetrator has been give
Hugo Mills wrote:
> I happily thought that the ternary operator had been put to death
> in Python, until I saw this little gem in some code yesterday:
>
> (is_forward and "F" or "B")
>
> The perpetrator has been given a good talking-to. :)
That's become a common idiom in Python, and most P
Hugo Mills wrote:
>If you were writing a function with a fast path and a slow path,
> which style would you use to write the function?
>
>
> Style A:
>
> if can_use_fast_path:
> return "fast path result"
> # do slow stuff
> return "slow path result"
>
>
> Style B:
>
> result = "fast path
On Mon, Jun 08, 2009 at 11:45:29AM +0100, Victor Churchill wrote:
> On Hugo's second question, well yes different languages have different
> capabilities.
>
> So in perl one could boil the whole thing down to
> my $result = ($fast_path_applicable?) $fast_path() : $slow_path() ;
> return $result;
> So in perl one could boil the whole thing down to
> my $result = ($fast_path_applicable?) $fast_path() : $slow_path() ;
> return $result;
You can do the same in C - what comes out of the compiler is identical to
the simple "if" idiom I used earlier. So - for clarity - I'd still go for
that one.
On Mon, 2009-06-08 at 11:45 +0100, Victor Churchill wrote:
> And in a Quantum language you would just say what the heck and execute
> both of them in parallel anyway ;-)
Or start slow_path in another thread on another core, evaluate fast_path
and its viability in the main line of execution and the
Apologies, just seen the top-post above. My GMail is in idiot (basic
HTML) mode today and did not make it sufficiently obvious that it was
doing that.
--
Please post to: Hampshire@mailman.lug.org.uk
Web Interface: https://mailman.lug.org.uk/mailman/listinfo/hampshire
LUG URL: http://www.hantslug.
Another vote for the above
> if (fast_path_applicable) {
> result = fast_path();
> } else {
> result = slow_path();
> }
>
> return (result);
on the grounds of maintainability and clarity. I am not a bigot about
single-exits but this would actually be more debuggable too. Hugo's
original B was j
Vic wrote:
>>Assume that the fast path is a single expression, and the slow path
>> is at least tens of lines of code. Why would you pick one style over
>> the other?
>
> I wouldn't use either of the above.
>
> Style A has multiple returns from the function. That's one of those things
> that'
>Assume that the fast path is a single expression, and the slow path
> is at least tens of lines of code. Why would you pick one style over
> the other?
I wouldn't use either of the above.
Style A has multiple returns from the function. That's one of those things
that's just fine right up un
Hi
When looking at this I thought in terms of C and how it would code in
assembly. I also considered how easy and quick it would be to do jmp
instructions. On a slow Z80 it may make a difference on a superfast modern
machine would the difference be noticeable?
Considering this Style B is fa
On Sunday 07 June 2009 21:39:44 James Courtier-Dutton wrote:
> I would aim for a function to have a single entry point and a single
> exit point with goto's used on the error paths. I.e. the Linux kernel
> style.
I tend to aim for a single exit point as well, with the caveat that
readability trump
2009/6/7 Hugo Mills :
> If you were writing a function with a fast path and a slow path,
> which style would you use to write the function?
>
>
> Style A:
>
> if can_use_fast_path:
> return "fast path result"
> # do slow stuff
> return "slow path result"
>
>
> Style B:
>
> result = "fast p
2009/6/7 The Holy ettlz :
> On Sun, 2009-06-07 at 20:34 +0100, Hugo Mills wrote:
>> >
>> > Hmm. I'd choose Style A since with Style B there's a chance I'd have to
>> > discard one result and evaluate three things. Unless there's some
>> > parallel funny-stuff... what's the probability of can_use_fa
To me, Style A is much clearer and more logical. Style B is favoured by
those who prefer obfuscated code. Just my opinion, of course...
Perhaps more importantly, there is presumably a reason why, in some cases,
the fast path result cannot be used. Therefore the first line in Style B
will result in
On Sun, 2009-06-07 at 20:34 +0100, Hugo Mills wrote:
> >
> > Hmm. I'd choose Style A since with Style B there's a chance I'd have to
> > discard one result and evaluate three things. Unless there's some
> > parallel funny-stuff... what's the probability of can_use_fast_path?
>
>*shrug* Who kn
On Sun, Jun 07, 2009 at 08:30:23PM +0100, The Holy ettlz wrote:
> > > > Style A:
> > > >
> > > > if can_use_fast_path:
> > > > return "fast path result"
> > > > # do slow stuff
> > > > return "slow path result"
> > > >
> > > >
> > > > Style B:
> > > >
> > > > result = "fast path result"
> > > Style A:
> > >
> > > if can_use_fast_path:
> > > return "fast path result"
> > > # do slow stuff
> > > return "slow path result"
> > >
> > >
> > > Style B:
> > >
> > > result = "fast path result"
> > > if !can_use_fast_path:
> > > # do slow stuff
> > > result = "slow path result"
>
On Sun, Jun 07, 2009 at 08:16:34PM +0100, The Holy ettlz wrote:
> On Sun, 2009-06-07 at 20:01 +0100, Hugo Mills wrote:
> > If you were writing a function with a fast path and a slow path,
> > which style would you use to write the function?
> >
> >
> > Style A:
> >
> > if can_use_fast_path:
> >
On Sun, 2009-06-07 at 20:01 +0100, Hugo Mills wrote:
> If you were writing a function with a fast path and a slow path,
> which style would you use to write the function?
>
>
> Style A:
>
> if can_use_fast_path:
> return "fast path result"
> # do slow stuff
> return "slow path result"
>
>
If you were writing a function with a fast path and a slow path,
which style would you use to write the function?
Style A:
if can_use_fast_path:
return "fast path result"
# do slow stuff
return "slow path result"
Style B:
result = "fast path result"
if !can_use_fast_path:
#
35 matches
Mail list logo
