Developers

[Komag]

joetesta's project of 30,000 lines of code (https://forums.roku.com/viewtopic.php?f=34&t=89748) is still the biggest reported.

My game is up to over 16,000 lines now (about 900k of code, still roughly half comments), so when it was 7600 lines and I thought I might be about halfway done, I was wrong wrong wrong! But I'd say I'm definitely more than halfway done now 😄

[EnTerr]

"Komag" wrote:
joetesta's project of 30,000 lines of code (https://forums.roku.com/viewtopic.php?f=34&t=89748) is still the biggest reported.

My game is up to over 16,000 lines now (about 900k of code, still roughly half comments)

Hmm, to give you a perspective, a current version of a Lua interpreter (a scripting language more powerful/faster than B/S) weighs at only 24k lines (1100kb) of C. C is less expressive (i.e. verbose) than higher level scripting languages, so one is left to wonder what is it that you guys are doing to reach such high numbers?

[Komag]

Probably lots of inefficient newbie spaghetti code! But I do try hard to avoid repetition if possible.

[adrianc1982]

you should avoids comments as much as posible. rename your variables in a more descriptive way even if you have to use long variable names. coments are evil, your code should read like a big coment if you are doing it properly.

functions should have descriptive names long ones if posible and you should write 3 lines per function or less when posible.

my code is 6000 lines of code no coments. going to push it to 8000 or 9000 lines of code.

[EnTerr]

"adrianc1982" wrote:
functions should have descriptive names long ones if posible and you should write 3 lines per function or less when posible.

Goodness gracious, NO!
Whoever came with such idiotic idea must been someone from the Marketing Department of the Sirius Cybernetics Corporation ("A bunch of mindless jerks who'll be the first against the wall when the revolution comes"). Prophetizing this should be outlawed.

A function should be as long, as it makes sense; as much as you - or a developer after you - can hold in their head and work with. It also depends on what is being done - there are cases in which hundreds of lines are okay, i won't preclude thousands if it was something linear and thinking free. Just like you cannot say "all roArrays should be <= 10 elements - or you are doing it wrong".

It's like arguing what's the perfect size of a coffee grind or meal pieces - it depends. But "2-3 lines" is like putting it in a blender and liquifying all to a smoothie! It's on the "too small" side, just like thousand lines is on the "too large" side, the golden mean is in the middle.

The problem with chopping to too small pieces is that you have not got rid of complexity. Complexity hitting the fan did not make it disappear per se - it gets it smeared all around. Even if you can hold in your head all the million pieces you shattered it into, the coder after you can't - or they'll need a week charting your function calls.

See discussions e.g. http://softwareengineering.stackexchang ... od-for-you

PS. and yes, comments should not restate what was said - or could be said - in code, for reasons of brevity and not running out-of-sync. But they could document why something is happening he way it is, external factors beyond the code. Say you have been told not to do that, because it doesn't work. Your code becomes more ornate and you have to note why it can't done simpler.

[marcelo_cabral]

Some stats from my open source game projects:

code+comments=total

https://github.com/lvcabral/Prince-of-Persia-Roku
6909+ 606=7813  (brs)

https://github.com/lvcabral/Lode-Runner-Roku
2757+235=3077  (brs)

[Komag]

"adrianc1982" wrote:
you should avoids comments as much as posible.... coments are evil...

But why? They help me think and remember how it all works together. Do they somehow hurt performance in the background?

[adrianc1982]

"EnTerr" wrote:

"adrianc1982" wrote:
functions should have descriptive names long ones if posible and you should write 3 lines per function or less when posible.

Goodness gracious, NO!
Whoever came with such idiotic idea must been someone from the Marketing Department of the Sirius Cybernetics Corporation ("A bunch of mindless jerks who'll be the first against the wall when the revolution comes"). Prophetizing this should be outlawed.

A function should be as long, as it makes sense; as much as you - or a developer after you - can hold in their head and work with. It also depends on what is being done - there are cases in which hundreds of lines are okay, i won't preclude thousands if it was something linear and thinking free. Just like you cannot say "all roArrays should be <= 10 elements - or you are doing it wrong".

It's like arguing what's the perfect size of a coffee grind or meal pieces - it depends. But "2-3 lines" is like putting it in a blender and liquifying all to a smoothie! It's on the "too small" side, just like thousand lines is on the "too large" side, the golden mean is in the middle.

The problem with chopping to too small pieces is that you have not got rid of complexity. Complexity hitting the fan did not make it disappear per se - it gets it smeared all around. Even if you can hold in your head all the million pieces you shattered it into, the coder after you can't - or they'll need a week charting your function calls.

See discussions e.g. http://softwareengineering.stackexchang ... od-for-you

PS. and yes, comments should not restate what was said - or could be said - in code, for reasons of brevity and not running out-of-sync. But they could document why something is happening he way it is, external factors beyond the code. Say you have been told not to do that, because it doesn't work. Your code becomes more ornate and you have to note why it can't done simpler.

I respect balance, you could write a lot in 3 lines of code and a lot of operations in 3 lines of code. Also trying to stay at 3 lines is not the same as DO only 3 lines just try to make functions as short as possible for reusing. Functions should only do 1 thing and only 1 thing, a function doing 2 things is a bad written function you may say whatever you like we all have our coding techniques and opinions. You may even be better than me at coding but short functions are reusable and can be copy pasted for a future proyect long functions on the other hand have to be adapted, but we can discuss this all day long hehehe.

[adrianc1982]

"Komag" wrote:

"adrianc1982" wrote:
you should avoids comments as much as posible.... coments are evil...

But why? They help me think and remember how it all works together. Do they somehow hurt performance in the background?

please buy this book

Clean Code: A Handbook of Agile Software Craftsmanship
 

Robert C. Martin

It has a lot of great insight and once you read this book your coding WILL CHANGE. He is not right all the time on his advice but most of the time is spot on.
Coments are evil and most respected coding sites or books will tell you about it, Robert Martin has his say on coments and even though i dont remember by heart and i read this book a while ago more or less he explains coments get outdated fast.

How come can coments get outdated? well lets say you have written thousands of lines of code and you need to refactor or rewrite a good portion of it, or lets say you wrote version 1.0 and you are going to do version 2.0 thats bigger and better and flashier. You are going to modify code and you will have to work twice just to keep coments updated on what you did, and you will modify code maybe hundreds of times until you get it right. I dont think you will modify that coment 100 times and by the time you know your code like the back of your hand you will just ignore the coments and coments will say something wrong about the next piece of code because think about it, you dont need the coment for code to work.

Most programmers and that includes me just ignore there own coments and just make code work and coments will be wrong and misleading, its bloat, you should on the other hand write variables as long and descriptive as posible and make it as if you were writting a book that you or another coder can come back later and read easily without all those coments that dont make sense. Your code is what we will read make it readable dont write variables like x = something or y1 = x+yz because thats why you are probably writting coments. If you write proper code coments become useless and you are probably writing a lot of coments because you are new to coding later on you will understand all code perfectly and wont need that.
Maybe by the time you are done and you want to write another piece of software you will just skip those. But please read the book its a short read and it will give you tons of advice early on now that you are writting code. I wish i had read this book earlier..

[Komag]

I imagine there is a lot of truth to that. I am indeed completely new to this stuff. The good news is that no one will be reading through my code or comments, so it's all just a learning experience for me!