Comment by segfaultbuserr | Hacker News Reader

Comment by segfaultbuserr | Hacker News Reader

Parent Full thread

Honestly, not too bad. At least it's organized as recognizable functions. It just has a lot of useless repetitions that should've been implemented as lookup tables or format strings.

    datestr += '<option value="" selected>-mmm-</option>';
    datestr += '<option value="01">Jan</option>';
    datestr += '<option value="02">Feb</option>';
    datestr += '<option value="03">Mar</option>';
    datestr += '<option value="04">Apr</option>';
    datestr += '<option value="05">May</option>';

and

    case "alphanumhyphen": 
        if(l_str.length >0 && l_str.search("[^A-Za-z0-9\-_]") >= 0 ){
            if(p_alertFlg){
                alert( p_fldTitle +" should contain Alphabets or Numbers or - or _");
            }
            return "alphanumhyphen";
        }
        break;
    case "numeric": 
        if(l_str.length >0 && l_str.search("[^0-9]") >=0 ){
            if(p_alertFlg){
                alert( p_fldTitle +" should contain Numbers");
            }
            return "numeric";
        }
        break;
    case "decimal": 
        if(l_str.length >0 && l_str.search("[^0-9.]") >=0 ){
            if(p_alertFlg){
                alert( p_fldTitle +" should be Numeric.");
            }
            return "decimal";
        }
        break;

What is the correct term to describe this type of code?

I used to call it "Spaghetti Code". But I recently learned that it's incorrect. "Spaghetti Code" only refers to programs with messy and unclear control flows (especially unstructured programs that abuse goto), it's not the correct term for code with useless repetitions.

On the positive side, it's straightforward and is void of cleverness (yes I've been doing Go, can you tell?).

I mean if I were to change that option string generator, I could make a numeric for loop from 1 to 12, left-pad a zero for the value, and lookup the month label from a label array or create a Date object and use its formatting options to output the label. I loop over an array of objects with a value and label. With ES6 I could do that with a .map() operation.

It's inelegant but it does what it says on the tin. Can't have an off-by-one error if you don't use loops or indices.

On the other hand, look at the validation:

- Why not check the length of the string before the switch? - Why return a string which is (meant to be) identical to a variable? - Why not set the regex into a variable and then only have one if-block?

"Don't repeat yourself" is a very good rule for many very good reasons, but a big one is that you don't have to change 10* different places to change 1 thing, which gets rid of a whole class of extremely common bugs. Also, it makes it much more obvious what the code is doing, since your brain only needs to parse 10 different one-line assignments instead of 10 different six-line blocks.

* Replace "10" with whatever the actual number is.

For sure. Using code or data structure to generate code is recent (or resurrection ) phenomenon of function programming.

The function is formatted and it does what it suppose to do. It can be refactored to make it less code.

> Using code or data structure to generate code is recent (or resurrection ) phenomenon of function programming.

I'm not entirely sure how you came to that conclusion. Lookup tables and format strings have been around for... well, I'd guess almost a century.

WET code?

https://en.m.wikipedia.org/wiki/Don't_repeat_yourself

Ah, thanks. I didn't know DRY has an antonym - WET. I followed the link and saw that this behavior is also called copy-and-paste programming. I think I'll use this one from now on. Wikipedia has a funny animation for that.

https://en.wikipedia.org/wiki/File:Forgotten_edits_in_copypa...

Except DRY is not about not repeating code at all. It's about having a single source of truth. I'm not saying this is the case here, but it's a problematic misconception because it encourages pre-emptive optimization of repetitions that can be purely coincidental and not rooted in business requirements.

Write Every Time fits. I like this.

I think the scientific term is "boring, maintainable code that junior overengineers won't touch with a stick"

This is your idea of maintainable? Yikes. Tell me, how many places in the referenced snippet would need to be changed to, say, allow commas to be present in numbers?

Yep. All the duplication is local and it's just a few lines.

Duplication is never pretty, but when it's as local as here, it's pretty much harmless. Duplication that's not obviously duplication, that's a problem. This is not that.

To answer your question, in 3 places, a few lines apart from one another.

Now what happens when there are 10 of these blocks? Embedded within or called by 10 other blocks that also have duplication?

Duplication displays exponential growth.

I suggest "micromanaging". Instead of saying "do this 100 times for these parameters", you explicitly instruct to do things one by one without noticong that there's a pattern in your instructions.

Its cautious - each engineer that edits that file is changing the minimum necessary. You can bet a bunch of them looked at some of those functions and saw how they could be made more consise or less repetitive - but if its all working why take the risk? Its just creating more work for the people downstream who have to test and sign off every change.

There's a lot to be said for boring, easy to understand code.

Strings are immutable, so each one of these concatenations creates a new string with slightly more content.

I have seen modern JavaScript that can be just as bad as this.

Most modern JavaScript I've seen is worse than this.

At least it's not a minified blob built up from dozens of repos whose primary purpose is to make its authors look (feel) productive/prolific.

Not really correct for JavaScript (among others). All modern implementations optimize repeated appends in cases like this. They all have ropes, too.

i have this kind of code only difference is it is autogenerated using code templates, changes to templates are done by developers already experienced in the code and bug fixes in actual code are done by junior developers may be this is not handwritten.

Pasta code.

I like where this is going, so I propose gnocchi code: small blobs of pasta tightly packed together.

Or just generally starchy code?

Now I just want to figure out all of the food analogies for bad code patterns...

Is high starch code (once its been DRYed) less susceptible to code rot and code smell? Though it may be less nutrious and so should be near the bottom of the code pyramid.

Reply on news.ycombinator.com