Skip to main content

In All Things, Make Thyself Simplicity

    So goes the saying above, which I've heard for most of my life and yet currently can't find an author it's attributed to. Marcus Aurelius? Paul the Apostle? Brilliant 21st century writer Max "Edison" Engel-Streich? The world may never know for sure.
    But, as it does with "all things," the above rings true for coding as well. As a thinker (and speaker, and writer, and communicator, and texter, and blogger, and journal keeper...the list goes on) it's commonly tempting for me to really hammer a point home by over-explaining it, and then re-explaining it (just in case I missed something the first time). So it was no surprise to me when I forced myself to stop for a moment and re-evaluate how much extra syntax I was putting into my code.

Take the below problem:
// Our task is to print:

    // - "AA" if marks is greater than 90.
    // - "AB" if marks is greater than 80 and less than or equal to 90.
    // - "BB" if marks is greater than 70 and less than or equal to 80.
    // - "BC" if marks is greater than 60 and less than or equal to 70.
    // - "CC" if marks is greater than 50 and less than or equal to 60.
    // - "CD" if marks is greater than 40 and less than or equal to 50.
    // - "DD" if marks is greater than 30 and less than or equal to 40.
    // - "FF" if marks is less than or equal to 30.

    // 🚨 Format your if...else if...else conditional below

(all credit and copyright and glory to FlatIron School).

    My initial thought was how important it would be to make use of javascript's built in function to accept two parameters which both need to be true - ie "&&." On second thought, I realized, that would be redundant. Two important things to consider:
(1) That the code is read from left to right, and top to bottom.
(2) Practical mathematics.
(3) Built in operational efficiency.
    Here's what I mean:
(1) The code will inherently read and analyze the first line first - if the input is higher than 90 - and then the second line second - if  the input is higher than 80.
(2) A number that is lower than 90 inherently fails the first if statement. If it is higher than 80 it inherently passes the second statement - and is inherently lower than 90.
(3) Thanks to the functionality of javascript, once a condition is met, the loop automatically exits. Even though a number that is higher than 80 is also inherently higher than 70, 60, etc, the code will automatically only fulfill the first condition that is true, and then exit the loop. As such, I decided to lean in to "simplicity" and leave the second condition out of the parameters list. My resulting code looked as follows:

if (marks > 90) {
    console.log("AA");
        } else if (marks > 80) {
            console.log("AB"){
                }else if (marks >70){
                    console.log("BB")
                        }else if (marks > 60){
                            console.log("BC")
                                }else if (marks > 50){
                                    console.log("CC")
                                        }else if (marks > 40){
                                            console.log("CD")
                                                }else if (marks > 30){
                                                    console.log("DD")
                                                        }else {
                                                            console.log("FF")
                                                                }

(Cascade added for readability/visual effect).

    The above code works! Just fine! It also got me thinking - if it was written "backwards" (testing for lowest value first, up to highest), then the second parameter, and the use of "&&" would absolutely be necessary. It would absolutely need to iterate through every stage of the loop looking for the correct range - otherwise the same value that should earn a grade of "AB" would automatically exit the code at "DD."

    Turns out, if statements aren't the only place that javascript wants me to use less text. Check out how I initially approached a "default variable":

function saturdayFun(soundsFun){
    if (soundsFun === undefined){
        soundsFun = "roller-skate"
    }
    return "This Saturday, I want to " + soundsFun + "!";
}
    That whole extra if statement is totally unnecessary. It should read like this:

function saturdayFun(soundsFun = "roller-skate"){
    return "This Saturday, I want to " + soundsFun + "!";

    I literally gave myself a face-palm when I learned how simple default variables are meant to be. But at least now I know for next time.

    I get the sense that the examples of places where javascript wants to do the heavy lifting for us run deep. Think about all the array functions (like .map() and .reduce()) that automatically iterate through each element for us. All of which feels like a simultaneous "big relief" and "rabbit hole of exploration I could wind up going down instead of actually sitting down and writing the code in a way that I already know would work even if the amount of text becomes slightly redundant." Which, I suppose, is the other end of the spectrum.
    In a lot of what I do (talking, texting, journaling) I have a tendency to over-communicate. Just  to make sure the other person definitely understands me. I have a feeling coding will be the same type of journey for me ("Will the program really execute this properly? What about x, y or z?"). One of the instructors at FlatIron School saw some of my coding redundancies, and paid them no heed. "First make it functional, then make it sexy," he pointed out. Truly wise words. Sounds like maybe I'm not the first person who went into coding with a tendency to overcommunicate, nor would I be the first person with a tendency to over-correct.
    Seems like the learning journey ahead could be a long one. Glad to know that javascript wants to at least help me with some of the heavy lifting along the way.

Comments

Post a Comment

Popular posts from this blog

If It Ain't Broke...

     I write you now, on a blog that was created as a requirement for a class, as a Graduate of that class ( hooray! ). But, like all good things in life, this space as an idea for musings has taken on a life of its own, and so I feel compelled to share another thought from the tech world I had: when did Gmail become the standard for online email? Seriously - in the Career Services literature that's given to every student following said class, this office - in charge of helping students find work in the field of technology - has this ("hot") take:  Email Address(es) : Should be @gmail.com @me.com or @customdomain. Avoid AOL, Hotmail or Yahoo email accounts because employers may view users with those accounts as out-of-touch or not tech savvy.     Reading this, I felt the sting of injustice (actually, more like embarrassment). I use a Yahoo email account! In fact - I have since high school! And what's wrong with that? It works just fine! And as my Grandpapp...
Post a Comment
Read more

The Power Paradigm: Metaverse edition

      This blog post will be slightly off the kilter of my usual writing. Not that I don't want it to be funny or engaging, but I'm not writing it with the same lighthearted intention that I've written about other, less-consequential topics like how to create tally marks or what I made my first website about. This post is also meant to be less results-oriented; there's no final product I want to show off or "behind the scenes" descriptor I'm writing. Instead, I want to use this entry as a jumping off point for discussing an issue that seems to be plaguing every aspect of society nowadays: the rise and dominance and social destruction as a result of: Facebook.     But, in particular, I've been curious: what role has their software-baby, ReactJS, played in this power struggle? It's been a hard question to answer definitively. For one, news coverage seems very intently focused on "one side" or "the other":     -It's very easy t...
Post a Comment
Read more

Tales From the Other Side: e.stopPropagation();

 Hello Readers,      Greetings from a chilly November day in New York. The kind of day that forces you to forget that Fall is after Summer, and to remember that Fall is before Winter. The kind of day that makes one glad they spent several years in Vermont and now have several tricks up their sleeve. Namely: warm socks and vigorous walking . But I digress.     The first 'tale from the other side' that I wanted to share is actually the one I was most excited about (in real time!) when I learned about it. Spoiler alert from the title: it's the event.stopPropagation() javascript method. So...what the heck is it?     Well, here's a few things about it: It's a native Javascript method, so there's no extra libraries, packages, components, syntaxes, etc to import. It's in the same 'family' as event.preventDefault() , so those familiar with other common event handlers may already have a sense of where it can be called. Think about all the ways...
Post a Comment
Read more