Other students:
#define redLed 2
#define yellowLed 3
#define greenLed 4
void setup ()
{
pinMode(redLed, OUTPUT);
pinMode(yellowLed, OUTPUT) ;
pinMode(greenLed, OUTPUT) ;
}
Me:
void setup ()
{
for (int i=2;i<5;i++)
pinMode (i, OUTPUT);
}
Proff - This code is wrong it won't work. Where have you specified red led, green led, yellow led?
Me - wtf! Code doesn't know which led is used in what pin it's just pin numbers!

Gave me less marks 😑
P. S. I wrote comments in my code specifying which pin will have what led connected 😑

To be quite honest, I have to agree with your professor. You're using magic numbers, which is bad practice. Defining your constants explicitly produces more readable and maintainable code.

If you want your program to be agnostic of LED colours, you could consider naming the constants 'led1', 'led2', 'led3', or even 'output1' 'output2', 'output3'. However, I would advise against building in unnecessary layers of abstraction.

@Grundeir @g-m-f This was a theory exam and time was short. I agree code may not be readable but it wasn't wrong. We had to write a simple traffic light program.
My point is justification given by him was completely wrong

@ujjwal96 are you in one of the Indian universities where they tell you to perform traffic signal practical using Beaglebone black?

@Grundeir Yes, hence the rant.
No, that's what is wrong with the system here. If you write something with correct logic but not how the teacher wanted you'll lose marks. I'm sure many Indian students can relate

@bugHunter Sir, in my university we don't have practical/lab for IoT (above code was asked in same subject's exam)

A idea on the matter from the Pragmatic Programmer: if you write code that nobody else understands you won't yourself understand it after few weeks. It's not a sprit, but a marathon.

By describing things as dumb as possible you decrease your OWN approach time to the code you are working on. If it's obfuscated by magic numbers it takes you x amount of time everytime you sit down to work on the piece. Declaration of variables/methods/functions and naming conventions have the sole purpose of unobfuscating. That's why int a, int b is bad what you are practically doing.

I agree with the Prof. Don't make this a question of misstatement but a chance to learn. Make it as dumb and as simple as possible everytime. That is the key to making the marathon.

@xios I agree with you and I'll definitely keep in mind what you said, thanks :)
But -
Please read the comments I already made.
When I asked him what's wrong, he said that you haven't specified what pin has what led(he thought writing redLed in code will make the redLed work and not the pin numbers) . He said that my code won't work.

@ujjwal96 I apologise. If the reason is "it won't work" I agree with your frustration.

@Grundeir I don't. When readability and maintenance is important yes. But when ur programming a micro-controller or a subroutine that might be running in million instances over scalable cluster every unecessary line of code matters (please dont start about in time compilers). Beside you can always comment those magic numbers. That being said best practice is: Apply accordingly to situation, so if readability wasnt a requirement tell your prof to go f himself. If it was then his right.

...But it works!!!
To make it shorter use:
pinMode(i , 1);

I agree that labeling what the pin numbers map to is a good idea to help you reason about your code as it gets more complex. But identifying that the same logic is being repeated and using a loop to isolate that logic is a great!

I think creating some sort of name => pin mapping and iterating over that would probably be an improvement over both...

@g-m-f In some certain cases yes it will. I recommend this book: "computer system a programmer's perspective". Although most of the modern JIT compilers don't care about certain assignments some of the lover lever compilers do. Assignment of 3 numbers to three different variables means (again depending on the system, consider low-level controllers and arm cpus) three extra copy operations for the cpu. Sometimes that means three extra cycles to do it (again not talking bout modern x86_64). When you have to do it over million times at once it can mean 3mhz of overhead for a tiny cpu. Point being: I'm 99% the professor gave him lower grade just because he was jealous he couldn't figure it out himself.

@provector Although, in this case, that code will clearly not run millions of times. It will run only once, in which case the more readable solution is the superior one.

Premature optimization is a common mistake; it costs a lot of time for no real gain, and in many cases reduces the overall quality of the code.

@g-m-f yes it does in certain scenarios.