33
dUcKtYpEd
53d

My first of "Stop doing" series of rants:

STOP WRITING WRAPPER FUNCTIONS AROUND NATIVE FUNCTIONS THAT DO NOTHING OTHER THEN PASS PARAMETERS THROUGH.

If its not significantly configuring values prior to using in the native function or combining several results, leave it be so NEW DEVS SUCH AS MYSELF aren't having to learn your shitty naming conventions wrapped around every native function to the language. Im a JS dev, not a Dave's witty web stack dev.

Comments
  • 7
    I never understood why people do this. The code base that drives me crazy every time I rant here looks exactly like that combined with essay type code and misspellings.

    "What's the point of this shit? Why?"
  • 3
    Not to defend it, because you should use it with caution and most people don't.. Especially web 'developers' (I am looking at you, the stack overflow copy&paste persons out there!) . But sometimes it's useful if you want to add default values or you plan to add some validation or modification in the data..
  • 3
    Wrappers, no. Composition, yes.
  • 6
    This can make sense but as a last resort.

    When you need to support an unstable, ever changing API by not (!!!) building a wrapper but in fact a proxy.

    Proxy as the function guarantees a stable API (parameters don't change) and internally fights the insanity to support the different API versions.

    Hence a proxy, as you not simply wrap, but instead have a middle man negotiating
  • 5
    I can put up with a lot of that crap if there are really good comments explaining why the code makes a business rule.
  • 1
    Uh, as an JavaScript Dev, I use wrappers around native and non-native callbacks to convert them to promises.
    #Make
    #JavaScript
    #Again
    #Proper
    #Async

    btw here is a nice helper if you want to reduce callback clusters
    https://github.com/fbarda/...
  • 8
    I usually do that when I use something OS specific and anticipate that I will need to do it differently on another OS. I want to encapsulate the resulting ifdef mess so that it doesn't sprawl throughout the whole codebase.
  • 0
    @SortOfTested yes yes yes to composition. Everything on this stack is very OOP styled. Not much composition, lots of class hierarchy and redoing the same thing over and over again with a different layer that slightly decorates it to meet its point of view.
  • 0
    @IntrusionCM agreed. We are using proxies quote often and providers. Then whatevers being provided will end up being a wrapper class 😂. Ima blow my brains out
  • 0
    @irene most of it is decently commented ill give it that. It depends on who worked on it and if its been refactored yet. We have 17+ contributors over 11 years
  • 0
    @irene most of it is decently commented ill give it that. It depends on who worked on it and if its been refactored yet. We have 17+ contributors over 11 years
  • 1
    @rutee07 a false sense of professionalism. Faking it til they make something of it. Something feels good about shoving individuals 'zens' of programming down everyones throats.
  • 1
    @melezorus34 If your naming them the same thats one thing or prepending "promise" or somethinh to the original native function name then thats comprehensive. But writing a function splitName(name){return name.split(" ")} instead of just writing name = origName.split(" ") is infuriating.
  • 1
    @Fast-Nop now thats definitely an exception. Im working with react native write now that is sort of an example of that. Gives you its list of components and functions that act differently based on the OS.
Add Comment