Comment by NAFV_P | Hacker News Reader

Comment by NAFV_P | Hacker News Reader

Parent Full thread

> I look at this from the other side as well. I've worked with brilliant people with ivy league CS degrees who wrote much messier and less maintainable code than me, an autodidact designer/js dev with 1.5 years of experience. Maybe I'm wrong, and there was something in their code that I wasn't seeing, but I don't think so.

I would have ignored your comment were it not for you mentioning that you write javascript. I started learning it on and off a few weeks ago, and yesterday I installed spidermonkey as a standalone shell. What I have noticed is that a lot of the syntax that controls flow is very similar to C, which is notorious for being gibberish. I'm guessing the same will apply to js. I do not have a CS degree, but would you say that this is readable? This is a function for extraction of nodes in a double linked list that I am currently kicking into shape.

  /*
  *	extract *p__ from p__.
  *	but original *p__ is shifted left or right \
  *	    if there is still space.
  *	extracted ndi* is returned, but the remainder of the list \
  *	    is sewn back up.
   */
  
  ndi *extract_ndi(ndi **p__, const int dec) {
      ndi *q_=*p__;
      if(dec>=_PREV_) {
	  *p__=*(q_->lnk+dec); /* the shift */
	  if(*((*p__)->lnk+!dec)=*(q_->lnk+!dec)) { /* sew up */
	      *((*(q_->lnk+!dec))->lnk+dec)=*p__;
	      *(q_->lnk+!dec)=NULL; /* burn ends of extraction */
	  }
	  *(q_->lnk+dec)=NULL;
      } else if(dec==_LONE_) /* final possibility is that *p__==NULL */
	  *p__=NULL; /* ie. dec==_DEAD_, no which ain't it not worth man */
      return q_;
  }

What the hell was I smoking when I wrote this? I can't even read it myself.

Writing convoluted code is more to do with a certain state of mind. You should ask your coworkers where they obtain LSD, not where they got their degree. I haven't come across any acid for about a dozen years, I think it has gone out of fashion.

Of course if this was Perl it would be even worse.

> What the hell was I smoking when I wrote this? I can't even read it myself.

It's what you get for being lazy (non judging here, I'm guilty of it too) and not naming your variables accordingly. When you write the code you probably know what ndi, q, p, lnk, etc. are supposed to mean. But then you leave the code for some time and when you return you are lost. Just write out variable and function names so that your code reads like english - programming Obj-C for some time really helped me there :)

And with pointer-heavy code I tend to create aliases for offsets so I don't have to write out things like *(q->lnk+!dec) every time I reference that specific address.

Yes, maybe it will cost me wizard points with colleagues because they start to understand my code but my sanity is it worth to me ;)

(Also trailing/leading underscores are the devil!)

I'll confess, it is deliberately obfuscated. *(q->lnk+!dec) and the like were originally written in macro.

> Of course if this was Perl it would be even worse.

Sigh. Sadly, it has become fashionable to bring up Perl only to ridicule it even when there is absolutely no context or need.

Take a look at this implementation [1] of doubly linked list in Perl. Tell me how that is worse [2].

Now, I will go back to my corner to being productive using Perl or whatever language I need.

[1] https://metacpan.org/source/LEONT/List-DoubleLinked-0.003/li...

[2] Of course, I have no way of knowing if it is an exact or even close translation of your code, but it does implement doubly linked lists.

> Sigh. Sadly, it has become fashionable to bring up Perl only to ridicule it even when there is absolutely no context or need.

A lot of people ridicule C, I just laugh my head off.

Apologies, I assure you that I am not ridiculing it. The elegance of a language is not my concern. In fact, your comment has made me decide to put some effort into learning a bit more Perl, but I will have to find some time.

What I find when I work with "pointy" data structures is that it really, really helps to draw diagrams to clarify your thinking. I can write a doubly-linked list extraction with my eyes closed (and it'd probably help to do it with closed eyes, since I can more easily picture what's going on) but it very likely won't look anything like yours... what's dec for? And all the extraneous underscores in the variable names, I don't see why you need them. What's wrong with p and p?

One underscore indicates a pointer, two indicates a pointer to pointer.

Drawing diagrams is one of the most useful teaching strategies I've found when people are just starting to learn pointers. I've TA'd a course that introduces students to C++, pointers, and basic data structures, and after five semesters, I'd say that it's the single most helpful thing I've found when they are first trying to wrestle with pointers. (They get to implement a doubly linked list.)

The code was a little convoluted, but those comments totally cleared things up.

Sure, "/* ie. dec==_DEAD_, no which ain't it not worth man */" really cleared things up.

If you think that snippet was bad, you should see the rest of it. It covers nine files and around 500 odd lines.

Good practise though.

A little whitespace goes a long way. Were the list elements also stored in sequence in some array, or is ->lnk a two-element array with the forward and backward pointers?

The latter applies here, this is the node:

  typedef struct dll__ {
      struct dll__ *lnk[2];
      void *dat;
  }ndi;

I've seen some examples on the web, but I haven't seen it done this way. I have a suspicion it might be slower than the traditional technique, but I'll have to check that. What is not evident from the code snippet is that I'm trying to make the code handle both fixed end and looped lists.

So you never told us what you were smoking.

I cannot remember, but it was damn good stuff.

Reply on news.ycombinator.com