LÖVE

Best: Indentation, indentation, indentation. I like clean code formatting. Even if it's a bit complex. I like being able to tell where functions and loops and if statements start and end without having to read.

Worst: I don't comment much at all. I know I should, but since I can read the code I rarely think I need to comment.

I also use short variable names, mainly to save typing time. If I could, I'd abbreviate everything. At one point I actually was using plyr instead of player because it saved me two characters to type. And because for some stupid reason, when I type player, I almost always hit plater instead. But when I type plyr, I don't. Probably something to do with me not needing the A and E which are on the left side of the R. (I now use player.)

I also put too much code in one file. I only have 7 main files for the thousands of lines my Adventure engine has. I keep meaning to split it up more, but I just never know which functions to put where.

Also, no goal either. I start so many project types and get bored of them or run out of ideas to make it work and abandon them. I've restarted different game types so many times because I thought I had a better method to do it.

Oh, and the same as tentus. I usually end up making really large functions. I've been called on it before, but hey, I code in a stream. Maybe later I take some code that will be used many times and make its own function, but a lot of the time it's a few large functions.

Jasoco wrote:Oh, and the same as tentus. I usually end up making really large functions. I've been called on it before, but hey, I code in a stream. Maybe later I take some code that will be used many times and make its own function, but a lot of the time it's a few large functions.

Oh, yeah. I do that too. Especially when combined with the overly clever code and lack of comments mentioned before, this makes my code sometimes a maintenance nightmare.

My best: I'm very good with indentation, and I usually am very good at separating each part on its own function/file/class. I've learnt how to do that right from Ruby. I learnt how to do it wrong every time I work with PHP. So I'm good at not creating spaguetti code.

My worst: Sometimes I make so many classes, small functions and files that my code starts looking like layers over layers over layers, so much abstractions on top of another, that it isn't short or maintainable any more. It's lasagna code.

So, yeah. It all begins and ends with pasta with me.

Oh, and I don't usually abandon projects, but they have long hibernation periods.

I see a few people mentioning that a good coding practice is to split up code into multiple files. How does one go about doing this? I don't have any experience working with the love.filesystem functions.

Fourex wrote:I see a few people mentioning that a good coding practice is to split up code into multiple files. How does one go about doing this? I don't have any experience working with the love.filesystem functions.

You use the require directive and love.filesystem.load. I've done a chapter about splitting your source onto several files on my tile tutorial.

Thanks for the help! This will come in handy.

Best: Consistent code style. Having the style of your code kept strictly to set guidelines makes it far easier to read, for yourself, and especially others (ever tried reading inconsistently styled code?).

Worst: Not testing often. If you don't test what you've written a lot (make a change, test, repeat) the likelihood of errors and bugs goes up. Errors are usually harder to work out as well, because often there's a whole chain of errors you've written with each one of them adding to confusing mess. I struggle with this quite a lot myself, especially when I keep getting ideas.