How Big projects can Löve2d handle?

[ivan]

This can spot only compile-time errors, but will miss run-time errors

Most compiled languages provide type safety which prevents a lot of run-time errors.
I'm not saying that it's impossible but that it is impractical to write a huge amount of Lua code and test it.

[kikito]

Most compiled languages provide type safety which prevents a lot of run-time errors.
I'm not saying that it's impossible but that it is impractical to write a huge amount of Lua code and test it.

I've been developing applications on dynamic languages for some years now and I think you are overrating compile-time type checks. On a 20k-lines project, you might get type errors maybe 2 or 3 times.

It's perfectly possible to write big programs without it.

For big software projects, what makes the difference is not strict type checking, but a complete, robust, automated test suites. Code that tests your app code and makes sure that everything works as intended. That's something you will have to do independently of the language you use. Yes, it's more code, but it's just the professional thing to do.

[Robin]

I would argue the exact opposite: Lua, dispite being a small language, is quite expressive. I've read somewhere that, no matter what programming language, the number of bugs per line of code is roughly constant. So since Lua is so expressive, you are usually able to make a program that does the same thing as a C program, only with less than half the lines of code. Less lines leads to less bugs, and there you have it.

Plus it has automatic memory management, which makes a lot of thing much easier to deal with. Thus, less frustration. And less frustration leads to being able to maintain more code.

[Schreda]

Thanks for all your answers,

I was reading all posts... And it helped a lot thanks... By the way its not the first game and the reason why i want to use love2d is because of lua, lua was besides c the second language i learned and after a while i discovered that games which will be developed almost lonely c or c++ is not the key... Because its better to do a rapid development after you still can go for compiler language but with these cpu powers and memories today its sometimes not necessary to do it... Well than i will drive into it... thank you maybe server side i will use python ... Thank you regards

[pancakepalace]

If you have a problem not catching syntax bugs in code that is not being compiled it is either because 1) you don't know what you are doing or 2) the code doesn't matter that much to you. The larger the project, the more serious it will (or should) be. You don't invest time coding thousands of lines if you don't care about your project. If you indulge in such a large project, then you must be professional and unit test and profile your code. Good programmers test their code. Period. They also comment it wisely. Testing is not just for syntax bugs, but also for bugs that don't generate errors. Maybe you forgot to reset a counter, etc... The problem with large code shouldn't be more bugs, but the architectural problem of scaling. For this, you must plan your app well and isolate code in reusable and testable blocks. After you spend 6-8 hours coding a class, please spend another day commenting it, writing unit tests, and writing examples for it. The will pay off in the end. Unit tests are important, because if you change the code, you can run them again to see if you introduced new bugs. Comments make your code easier to maintain, and examples help you keep track of what all your code can do.

It doesn't matter if the language is interpreted or compiled, if you have thousands of lines of code and you don't unit test, you will have bugs. That's a promise.

[kikito]

Comments make your code easier to maintain, and examples help you keep track of what all your code can do.

I agree with most of what you said, except for the parts regarding comments. I'm sorry if this is going OT

Comments regarding licensing - MIT, GPL or what have you - are acceptable.

"Code examples" should not be put into comments. They should be on the tests. Test suites are not only a "safety net", they are also a low-level documentation of what your code does. And, contrarily to comments, they are in sync with the code.

Comments do *not* increase code maintainability - first of all, because they also have to be maintained: When a function changes, you have to change its code and also its comments. It's actually more work. Secondly, a clarifying comment is a symptom that the code isn't clear enough to understand in the first place. If you have a piece of code that isn't understandable enough, instead of wasting time writing a clarifying comment, make the code clear.

Each clarifying comment is, at heart, a tacit admission of a failure. Writing them should hurt - just like copy-pasting code.

[slime]

Comments do *not* increase code maintainability - first of all, because they also have to be maintained: When a function changes, you have to change its code and also its comments. It's actually more work. Secondly, a clarifying comment is a symptom that the code isn't clear enough to understand in the first place. If you have a piece of code that isn't understandable enough, instead of wasting time writing a clarifying comment, make the code clear.

Each clarifying comment is, at heart, a tacit admission of a failure. Writing them should hurt - just like copy-pasting code.

I would agree with this if people wrote code in a vacuum, but that's not the case. 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.

[T-Bone]

Comments do *not* increase code maintainability - first of all, because they also have to be maintained: When a function changes, you have to change its code and also its comments. It's actually more work. Secondly, a clarifying comment is a symptom that the code isn't clear enough to understand in the first place. If you have a piece of code that isn't understandable enough, instead of wasting time writing a clarifying comment, make the code clear.

Each clarifying comment is, at heart, a tacit admission of a failure. Writing them should hurt - just like copy-pasting code.

I would agree with this if people wrote code in a vacuum, but that's not the case. 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.

Just because code is clear, does not mean it's perfect. Especially if it's a one man project, the code really only has to be clear enough for you yourself to understand (but you should be able to understand it in a year, too). That doesn't take hours of thinking.

I do however think comments are useful, but for me it's more for the sake of summarizing; if I have a .lua file of a couple of hundred lines, putting a few lines of comment on top naming the most important functions and the order of their input makes it easier than finding the function in the code, even if you ctrl + f. Especially if you forgot its name.

However, the more I code, the less I comment. Not sure why.

[kikito]

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.

[pancakepalace]

Obviously, code examples should be on their own page. I usually do a type of manual for my classes in markup language.

- - -

Your code should definitely be as clear as possible, but comments are useful in several circumstances:

1) complex algorithms:

It doesn't matter how clear and easy to read your code is, it won't diminish the complexity of your algorithm. Sure, sometimes this complexity is due to bad planning and architecture, but sometimes there is no way around it. Some algorithms are complex. When you have 10 lines of code accomplishing a really complicated task, it can help a lot to comment that.

2) Exceptions:

The devil is in the details. Usually, a large portion of code deals with exceptions. It's good to comment this. It helps maintainability. If you have a bunch of lines that tackle a tricky problem that occurs in some obscure situation, I'd like to know this information if I was tasked with maintaining your code. Why should I have to read through your code and follow the breadcrumb trail to find out the function deals with something that happens almost never.

3) IDE's and comment parsing

Development tools can be linked with the comments for fast searching through code. Here's a simple example with some comments that describes the first function. I can set my IDE to parse for the comment @uses and quickly find out which functions use which others. I can also generate documentation markup automatically with this data. Essentially, comments can be parsed.

Code: Select all

--[[
    This is some Function.

    @params   none
    @returns   none
    @uses       someOtherFunction()
--]]
function someFunction()
end

function someOtherFunction()
end

Obviously, there is such a thing as bad comments. Comments that comment the obvious are bad. The trick is to know what to comment and what not to comment. Saying that comments don't help maintainability is ludicrous in my opinion. Good comments do help maintainability. Go back to some of your code that you wrote 3 years ago and see if helps when there are comments. A lot of times, you'll wish you'll have commented this or that.

As a freelancer, I always look at the code before deciding to embark on a maintainability job. If there are zero comments, I usually say no instantly. I don't want to have to learn all the code and classes if I'm planning on simply changing a few features. I want to figure out where the important stuff is real fast. Time is money.