in reply to On elegant coding...
in thread Just thinking ...

Being a former logic programming daemon, let's take a completely different take on writing this. Among other things, this different take shows that you should use constants instead of strings to avoid spelling errors. 
  ## main loop
  if (cache_is_good()) {                 
    show_cache_and_exit("current");
  }

# INSTEAD BECOMES

   cache(GOOD) && show_cache && exit('current');

[download]

  if (cache_is_stale()) {
    if (i_am_the_writer()) {
      if (i_can_fork()) {
        if (i_am_the_parent()) {
          show_cache_and_exit("stale");
        }
        ## child does:
        be_a_child();
        update_cache();
        exit 0;
      }
      ## cannot fork, so it's up to me
      update_cache();
      show_cache_and_exit("current");
    }
    ## I'm not the writer, so show old cache
    show_cache_and_exit("stale");
  }

#### BECOMES
(cache(BAD) && sleep(5) && redo)
             ||
(cache(STALE) && 
  (!i_am_writer && show_cache && exit(STALE))
             ||
  (
  i_am_writer && 
  (forkable() && (
   (parent && show_cache && exit(STALE))
      ||
   (child  && update_cache && exit(0)
   )) 
   || (update_cache && exit(CURRENT)
  )

[download]
Prince "--'s here I come! Where is the preview button for comments? Why is this TEXTAREA so small? I cant see anything?" PAWN

Replies are listed 'Best First'.
RE: RE: On elegant coding...
by merlyn (Sage) on Oct 14, 2000 at 07:57 UTC
    I shun this coding style, because it either implies an additional dependency which doesn't exist, or introduces a dependency which shouldn't be there.

    If you use 

    a && b && c

    [download]
    where you mean 
    if (a) { b; c; }

    [download]
    and b returns false, you're hosed.

    Therefore, as an element of "elegance", I don't introduce or require any more dependencies than I can safely justify.

    In practical terms, I'd reject your code during a code review, demanding a rewrite on the grounds of maintainability.

    -- Randal L. Schwartz, Perl hacker

[reply]
[d/l]
[select]
      But I think it is perfectly OK to generate expectations of functions and develop code whose logic is dependent on it.
[reply]
        It is not really OK, but it is unavoidable.

        That said, it is still to be avoided where feasible.

        There is a big picture principle here. And that principle is that our ability to develop software is fundamentally limited by our ability to keep track of what is going on. So every step we take to avoid developing (or to remove) dependencies is another step by which we have extended what we can do with the software we are developing. You have by that much made it easier to develop more, fix bugs you find, and migrate support from one person to another.

        Pick up virtually any book on software engineering for more.

[reply]

In Section Meditations