>>26068

for i in range(1, 101): print(((i % 3 == 0) * 'Fizz' + (i % 5 == 0) * 'Buzz') or i)

Somebody's been watching Tom Scott...

>>26075
Not OP, but he did get me into fucking about aimlessly with Python and JavaScript.

>>26068

Clearest is always considered better, unless there is an obvious efficiency factor that makes another piece of code better (either in the sense of scaling the project later, or the runtime).


The example is obviously simple enough for anyone in the know to read that it doesn't matter, but code that someone else can pick up and read with the least amount of head scratching and trying to connect the dots is better.

>>26079
Exactly this. The code that you write, that other people can read an understand is always the best. If you get to be a professional programmer, you'll understand how you're nearly always working in a team, you're always inheriting legacy code (and therefore technical debt) and it doesn't matter how clever your predecessors were, if others can't pick it up quickly and use it, it is fucking useless.

Most junior programmers think/believe that they're the only people who are going to read their code.

OP I prefer the second version by a long way. It's longer, not as cool, but you can easily figure out what it is doing.

I'm not into programming, but would it then be advisable to comment on every line you can?

>>26083
No, too many comments can be as bad as none at all. A line or two at the start of each method/function (depending on what you're programming) and then a line or two above any complex logical blocks. You don't need to overdo it.

>>26083
No. If used sparingly but judiciously comments can be of immense help for future readers but they're not "free".

Comments act as noise when trying to read code so the value they add must be worth the distraction.

They also require maintenance just like the code does, otherwise they risk drifting from the code they comment. Whoever gets to work on the code next then has to track down whether the comment provides the correct intention but the code is wrong or if the code is correct but the comment's outdated.

>>26083

Good code should be fairly self-explanatory. If you're writing a lot of comments, it's usually a sign that your code is overly complex and insufficiently modular. Comments should be the exception rather than the rule, used to mark out gotchas or clarify things that are unavoidably complex.

Since any "coolness" is voided by its being fizzbuzz, you may as well opt for complete clarity.

>>26088
You're quite right. If anyone brought me fizzbuzz in an interview I would walk; lack of imagination.