Programming Slangs

It is sometimes difficult to cope-up with the ever-growing and ever changing industry and IT is the industry that brings different ideas, tools, tech and fun stuffs in the hands of all kinds of people, working for an IT industry or not.

Programming is something which is sometimes under estimated and definitely over judged at a few ocassions, but it is fun working in this environment which is not very different from any other work places. Like other places we have people who speak all kinds of languages (we don’t speak Java, Swift, C by-the-way), because of this internet era all kinds of people speaking different languages communicate with each other even if they don’t understand languages other person speaks. Programming language is one of the paradigm that puts all the programmers as a single entity but also diversifies them (by diversification I mean, communities within, that a programmer belongs to but, let’s talk about this some other day).

Like all other languages we do use slangs at our work place, Let’s see some of them and what they mean. These slangs are not at all important but, in my experience it helps programmers bond, as they can communicate better.

Spaghetti code

Most of the programmers have heard of this term and also sometimes used it while talking to their colleagues. Basically what it means is any software or a program that is unstructured and unorganised that follows no pattern as such that logically defines why is it done that way. below image might explain why it is called spaghetti code

Code smell

Most widely used term by developer community, it means that you code definitely works but will end up giving warnings or errors or bugs in future, these are not bugs but potentials future issues, some examples of these issues could be

• Creating a variable but not using it.
• A class or code base that is in a single file and that ends up with more that 600–700 line of code.
• A bunch of code that has been repeating it self more that twice at some places in your code base, this is a huge risk when it comes to maintaining the code for long term and so is declared a code smell or a potential issue. Now a days compilers are smart enough to optimise your binary and remove unused code as well but what about people reading your code your colleagues.

Stringly typed

This is not a typo, I wrote what I ment Stringly typed, this comes from the term strongly typed. Basically stringly typed means using a lot (a lot lot) of strings in our code, see below examples.

// providing the error message as part of the call
let errorAlert = Alert.show("Something went wrong!")
// providing the image name
let image = UIImage("company-logo")

At first glance you will say what is the problem in that, but when you have a team of 10 developers working in your code for more than 6 months, imagine the amount the hard coded strings you will be using at several places, now consider a scenario when you are asked to change the error message from Something went wrong! to Something went wrong, please try again! ,what would be your approach to it, you would find all existence of this and replace it with the new one. There is nothing wrong with that but, what if while replacing text you changed a file in which your colleague has made changes and is about to make a commit, I can bring all the real life problems here to make this difficult for you to maintain the code, but what if we could have avoided this by defining them at one place and use at all other places

struct ErrorMessages {
    // Can be updated to "Something went wrong, please try again!"
    static let genericError = "Something went wrong!"
}
struct Images {
    static appLogo = "company-logo"
    static backArrow = "back-arrow-black"
}

Use them at places like

// providing the error message, which is defined at one place
let errorAlert = Alert.show(ErrorMessages.genericError)
// providing the image name, which is defined at one place
let image = UIImage(Images.appLogo)

Now you know where to change and that would be just at one place.

Magic numbers

Numbers that can tell a fortune 😄, Jokes apart. These are the numbers that are hard coded in your code without explanation and they do something that makes your code work, but when a reviewer or a colleague looks at it, they make no sense to them. Think of a scenario when you are writing a function where you want to check if a prodduct is within price margin of ±10%.

let withinMargin = price > (price * 0.90) && price < (price * 1.10)

Now these are magic numbers that makes no sense to people looking at your code out of context and even you when coming back to your code after a few months might need a while to understand their usage.

You could have rather written.

struct Price {
    static let margin = 0.10
}
// your threshold calculation
let lowerThreshold = actualPrice * (1 - Price.margin)
let upperThreshold = actualPrice * (1 + Price.margin)
// your final code here
let withinMargin = price > lowerThreshold && price < upperThreshold

This code now is more spelled and easily understandable.

Rubber ducking

I heard this term in some online interview session back in 2017,
( In the interview. when I was stuck at a place the interviewer said “talk to the duck” and I was like aaaa what duckkk!!!).

Basically talking to a duck, does not mean talking to an actual duck. but an imaginary rubber duck. Now there are situations in a programmers lives when they are stuck at a place in some code and are trying very hard to figure it out and they might talk to a friend or a colleague to explain them the issue, While explaining the issue the solutions clicks to them instantly and they are like aah! never mind I got it. This happens to me a lot.

Smug report

This is something a very few people know but all of them have faced.

We all have situations when we have an issue from the field and the bug is reported by a customer in some sort of review or issue ticket or a service request. This is the situation when a bug is reported by a customer who thinks he knows all about what’s happening behind the scenes and very evidently suggests to fix that issue, but rather he knows nothing (like John snow, well he knew a few things but you customer does not.) that my friend is a smug report.

Refuctering

This is a funny one, it is exactly opposite of re-factoring, most of us have done some re-factoring to our code bases, sometimes to support new features some times to avoid deprecations some times to improve the architecture. But. when you end up ruining what was good and made it worse is refuctering, basically you f**ked up the code. Happens when we jump to a place of authority with no prior knowledge of what is happening but still want to make a difference 😆

Yak shaving

Funnier ones are yet to come, this is like shaving a yak, now by yak we are referring to all the tasks that we have to perform before we jump to start the code, let me put in conversation. A friend of mine joined a new company and I was talking to him the other day and was asking “how’s things going did you start coding are you liking it”, he said “Naah! I have to shave the yak first.”
Means he has to get all the stuffs done before he can do what he want’s to stuffs like, getting machine configurations done, getting credentials , getting git access etc,

Mad girlfriend bug

I promised you a funny one. It is not required for you to be in a relationship to understand this. This basically means that something weird is happening but your code says I am ok and everything is fine. (That should explain it.)

Jenga code

We all have played Jenga or seen people playing it, Jenga code is the same concept when you are working on a code base where you touch one thing and everything falls off and stops working, well that’s Jenga code.

I will be adding things here as an when I encounter new stuffs, Let me know if some slangs that you guys use at your work place will be fun hearing the new ones.