rotinstitute.blogg.se

1. #Funny abbreviations for words cto pro#
2. #Funny abbreviations for words cto software#
3. #Funny abbreviations for words cto code#

I understand that the aforementioned technique can be hard to push through code review.

#Funny abbreviations for words cto pro#

By the end of the project, that will make you a real pro coder, congrats!īad coding practices no. You get 10 respect points for using a reduce function and 100 points for making a recursion call. Because why write Date.now() if you can do the same thing with a bit more cryptic +new Date()? I’m sure your colleagues from the project will thank you for it when they will spend time trying to understand what the heck is happening in the code.Īnd remember: the more the code is overengineered and early-optimised the more you will make your coworkers struggle with it. I suggest you use chained functions, nested conditional statements, over-bloat design patterns and clever one-liners that use niche hipster features of the language you write in. So give it a go and write a code that proves you’re a real hacker. Of course, it will make the application harder to read and maintain but that will probably be your coworkers’ problem, right? Excellent! Maybe you can find some generalisation that will allow you to reuse three lines of code in two places by creating a method that accepts five parameters? Maybe you can reduce three lines of code into one by using a clever triple nested ternary operator? Your imagination is the limit! You just need to write your code in a bit more complicated way than it should be.

#Funny abbreviations for words cto software#

Here you will have an opportunity to prove you’re a Rick Sanchez of software development. One way or another, remember you can always promise to change it with the next pull request hoping everyone will forgive and forget your sin (and probably they’ll do).īad coding practices no. Maybe because you’re too lazy to fix it, or maybe because you need your troublemaker persona to maintain. Of course, all of this madness can be stopped during a code review but your job is to fight for it.

Instead of creating eg.: a readXmlDocument as the good practices recommend (abbreviations should be formatted like regular words) you can make a readXMLDocument method that will require the other developers to look closely and read the name more carefully to fully understand it. To add a little spice to the names you can always play with the casing, and I guarantee the co-workers will hate your guts for that. No discountedProducts for that poor soul, because the product’s name is still true and enough. The next developer will have to read the WHOLE code that returns the variable to understand what’s in it. You can do so much more with variable names! Have a list of unconfirmed users? Don’t call it uncofirmedUsers, just named it users. And unnecessary abbreviations like btn, func, config or cb make it even harder to understand. They don’t reveal too much what the functions are doing but you can still run with it during code reviews. Names like handleBtnClick, getConfig or parseInfo are good casual examples.

But we are not here to do a good job.įor bad results, always shorten and abbreviate the names as much as possible, so the next developer working on your code will have to guess what you were thinking about. I know, I know – it’s good practice to make all the names as descriptive as possible, right? Like handleFormSubmit, getUserConfiguration or parseCustomerInformation. For a good start, add some extra abbreviations to your variable or function names.