How Big projects can Löve2d handle?

[slime]

People write code to accomplish things, not for the sake of writing code. Instead of wasting your time pondering how to write clear, concise code with perfectly named variables (which is often impossible) for hours at a time, you can just put a comment there. That's one of the main purposes of comments.

I agree that finding the right name for variables is hard. But it doesn't take hours. It often takes seconds - and most difficult cases take minutes. Not only that, but a good design, and good names, do save hours in the long run. If it's taking you so long to find names, that can be solved with practice.

I'm not saying well-named variables aren't important, I'm saying it's actually impossible sometimes to write code that is understandable, works, and has no comments, like pancakepalace's first example.
Comments can also be really good for explaining the overarching goal of something, rather than what's happening right then and there, even when things have properly named variables.

Trying to make understandable variables 100% of the time can also lead to extreme verbosity, which makes me want to stab my eyes out. In my opinion, extreme verbosity (thisIsTheThingThatDoesBlahAndFooBecauseMyBossSaidSoAlsoItsAVector = vector(), for example) is much worse than extreme simplicity (v = vector()).

[TechnoCat]

Trying to make understandable variables 100% of the time can also lead to extreme verbosity, which makes me want to stab my eyes out. In my opinion, extreme verbosity (thisIsTheThingThatDoesBlahAndFooBecauseMyBossSaidSoAlsoItsAVector = vector(), for example) is much worse than extreme simplicity (v = vector()).

Code: Select all

v = vector()
v2 = v.s(2)
v3 = v.d(v2)

Code: Select all

thisIsTheThingThatDoesBlahAndFooBecauseMyBossSaidSoAlsoItsAVector = vector()
thisIsASecondVector = thisIsTheThingThatDoesBlahAndFooBecauseMyBossSaidSoAlsoItsAVector.scalarMultiply(2)
ThisIsEvenAnotherStupidVector = thisIsTheThingThatDoesBlahAndFooBecauseMyBossSaidSoAlsoItsAVector.dotProduct(thisIsASecondVector)

Which one is easier to figure out?

[slime]

Trying to make understandable variables 100% of the time can also lead to extreme verbosity, which makes me want to stab my eyes out. In my opinion, extreme verbosity (thisIsTheThingThatDoesBlahAndFooBecauseMyBossSaidSoAlsoItsAVector = vector(), for example) is much worse than extreme simplicity (v = vector()).

Code: Select all

v = vector()
v2 = v.s(2)
v3 = v.d(v2)

Code: Select all

thisIsTheThingThatDoesBlahAndFooBecauseMyBossSaidSoAlsoItsAVector = vector()
thisIsASecondVector = thisIsTheThingThatDoesBlahAndFooBecauseMyBossSaidSoAlsoItsAVector.scalarMultiply(2)
ThisIsEvenAnotherStupidVector = thisIsTheThingThatDoesBlahAndFooBecauseMyBossSaidSoAlsoItsAVector.dotProduct(thisIsASecondVector)

Which one is easier to figure out?

Your second example is realistic Java (:P), your first example isn't as realistic, as you'd probably use the multiplication operator (or the "mul" function name) instead of "s". It's usually best to strike a balance between your 2 examples, however shorter is often better than ridiculously long for variable names. My point was that trying to have expressive variable naming can result in ridiculous things, so if you really need to use a sentence to explain something then you absolutely should use a comment instead of the variable name.

There's a reason every language used in any modern program has the ability to have comments.

[TechnoCat]

There's a reason every language used in any modern program has the ability to have comments.

I like that point.

[Robin]

There's a reason every language used in any modern program has the ability to have comments.

But that doesn't mean that a program without comments is per definition badly written or illegible.

Good, readable code should have as few comments as possible --- but not less. Comments that explain what complicated algorithms do are not something you want to leave out. Explanations of implementation however means that you probably failed in writing clear code, and add an additional load to maintenance.

[pancakepalace]

But that doesn't mean that a program without comments is per definition badly written or illegible.

If it's a large project of 20,000 lines or more, then, yes, I would say it is badly written if there are no comments.