Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
Search - "programming debate"
So, just to recap if you missed the last few episodes. I've been a web developer for years. But I decided to get a degree and go to uni.
Also I am firmly on the fewer comments side of the debate about self-documenting code. Even though I usually rephrase it and say method and variable names are comments. Basic idea: something is unclear, you should leave a comment. But, before you leave a comment, take a good look at your method. Can you rename a variable? Maybe the method name? Maybe extract a method into smaller methods so it doesn't need a comment? And only if you fail to do so, leave a comment.
Alright, now that we rehashed that, uni coding makes no bloody sense.
There is code that is abbreviated to the max (or min).
And then, they need everything commented. I mean, why do that? Why call the parameters a and b instead of base and exponent. And then say:
"But write a whole article about it above the method". Like:
a is the base for a power operation.
b is the exponent for a power operation.
return int representing a to the power of b
How about just do this:
public static int power(int base, int exponent).
How is this not the same documentation?
Is it because we're at a uni, a place for smart people and smart people shouldn't have an issue keeping a mental map between the variables and their meaning?
Or is it because they are all mathematicians. All respect to applied mathematics. I mean, the function about exponent calculation, I was not aware that it could be that effective. But on the other hand, keep mathematicians away from programming. I get it, writing maths per hand doesn't have intellisense and therefore you don't want to write long variable names. It's and old tradition. Yada yada, yah.
But programming is not maths. And maths shouldn't be maths like that. Right naming makes it simpler. It might still be a while until we all LaTeX rather than handwrite and be able to give maths right naming schemes, but programming is beyond the point. Calling the array you handing in a function A and the one that you're returning D makes no fucking sense.4
Our company has the opportunity to start moving towards a more microservices architecture approach.
There is so much technical debt that needs to be paid back, this opportunity is a godsend!
Now, of course, the whole "programming language debate" comes into play at this point.
To provide some context, we've reached the point where we need to be able to scale, and at the same time where speed and performance are also important. I would argue that scale is of more importance at this stage.
Our "dev manager" (who is really only in that position since he's the oldest, like scribbling on a notepad and the sound of his own voice) wants to use Rust, as this is a peformant language. He wants to write the service once and forget about it. (Not sure that's how programming works, but anyhoo). He's also inclined to want to prematurely optimize solutions before they're even in production.
I want to use Typescript/NodeJS as I, along with most on the team are familiar with it, to the point that we use it on a daily basis in production. Now I'm not oblivious to the fact that Rust is superior to Typescript/NodeJS, but the latter does at least scale well. Also, our team is small - like 5 people small - so we're limited in that aspect as well.
I'm with Kent Beck on this one...
1. Make it work
2. Make it right
3. Make it fast
We're currently only at step 1, moving onto step 2 now!7