Code structure?

Hi,

so I've learn the basics of Lua/computercraft and I'm starting to write some codes for myself and recently I've started making sort of an OS but I have a huge problem, I don't know how to structure my code. I find myself putting huge chunks of code in one function or just using a bunch of function that all depends on each other and stuff like that.

Now if someone could tell me some pro tips on how to better structure/organise my code properly that'd be great!

Thanks!

Would it be possible for you to explain the situation more? May I see your code and suggest improvements that way?
It is hard for anyone to tell you how to structure your code as everyone structures their own code differently. I personally like to think of a function as a paragraph, so I make a new function every time I would take a paragraph in a story.
Sorry I could not be more helpful :(/>

Basically, any piece of code you need to execute from more than one place should be a function (Thanks for the wording Bomb Bloke )

Sometimes, long pieces of code that are only called once are put into functions. For example, a function to draw the screen of a program.


You can always check out programs on the forums to see how the author structured it!

I would recommend multifile code, which will allow you to better overview it. Also I would recommend to start small, and not with an OS.

Creator, on 26 December 2015 - 10:14 PM said:

I would recommend multifile code, which will allow you to better overview it

I ususally avoid more than 1 file simply because it makes the program harder to distribute. But for good OS, you'll certainly have multiple files, otherwise the single file would be thousands of lines and impossible to work with.

Creator, on 26 December 2015 - 10:14 PM said:

I would recommend to start small, and not with an OS.

Good point. It can be frustrating to get stuck on something you aren't sure how to do

HPWebcamAble, on 26 December 2015 - 10:21 PM said:

Good point. It can be frustrating to get stuck on something you aren't sure how to do

A lot of people try to start big with OSes and then get frustrated because it does not work. In the end they give up on CC. Don't go down the dark path.

A few tips:

1) Declare all variables, including functions, at the top (line-wise) of their respective scopes. If you don't know what a scope is, you've got a lot of learning to do :)/>. They are quite important and can produce frustrating errors when improperly used.

2) APIs are very helpful. If you find yourself repeating some bit of code over and over, you make it a function. If you find yourself accumulating functions, it's helpful to place these functions in an API. It helps if those functions are related, for example you might have an API named 'drawingUtils', which contains all sorts of things related to drawing the screen.

3) Always remember Lua code executes from top to bottom. So anything that isn't defined above a certain line won't be available when that line runs. This relates to my first point, placing variables at the top. In several languages (such as C), there is a "main" function which is defined, and then called after the entire program is compiled. In Lua, some people prefer to place all code that runs inside functions, and the "main" body of the program is placed inside a 'main' function, which is then called once at the bottom of their script.

4) Tables! Many programs require tables, and I think you will find any OS worth writing will contain many of these. You might even write extra functions for managing them.

Finally, I would urge you to spend a considerable amount of effort on your OS. It doesn't need to be as amazing as OneOS, but try not to be another NDF Jay clone. Too many copies of his OS with no added features have been posted by new users. And by new, I mean that was their first post, and possibly their last thread.

HPWebcamAble, on 26 December 2015 - 10:21 PM said:

Creator, on 26 December 2015 - 10:14 PM said:

I would recommend multifile code, which will allow you to better overview it

I ususally avoid more than 1 file simply because it makes the program harder to distribute. But for good OS, you'll certainly have multiple files, otherwise the single file would be thousands of lines and impossible to work with.

Howl can fix that but it does add more steps to your development cycle and could be too much for a new user.

First of all thanks a lot everyone, I surely will use these tips in mt future code.

I also won't be making an OS as i've realized that it was too big of a project for my skills.

Also if you guys have any idea of programs I could try to make that'd be great as I don't have much ideas…


Thanks again!

Most of us look at other people's scripts and think, "I would've done it like this…".

For me, "this" usually means "with more tables and loops". Don't get me wrong, you shouldn't shoe-horn in coding structures that you don't need, but most of the time a redundantly lengthy script will be that way because it's either not using loops correctly, or because it's not using tables at all.

So I guess my advice is to get familiar with for/while/repeat, and experiment with tables (nested ones in particular). Once you've got these concepts down pat you'll generally be able to write much more complex bits of code within much smaller spaces.

Creating a loop out of functions is to be avoided. If you need to loop, use one of the keywords provided specifically for the task.

HPWebcamAble, on 26 December 2015 - 10:10 PM said:

Basically, any piece of code you need to execute more than once should be a function.

Er, rather, any bit of code you want to run more than once should go into a loop; any chunk of code you want to run from more than one place should go in a function.

Some coders like to go overboard with functions. You end up having to read their scripts bottom-to-top, because every other line they're calling a new one and so you've got to constantly scroll the page around to keep track of where the execution order's going.

And these all tend to be one-shot functions, too - called from only one place. One-shots are indeed justified if they contain a great tract of code (eg - if you have a menu, then the code for the menu itself will be a dead nuisance to read if you don't bundle its options off into functions), but their numbers should be kept to the barest minimum.

I often get the impression that people hear the line "good code doesn't need comments" and decide to cheat, putting in a new function name every time they should really just be putting in a comment. Yes, a function's name should describe what that function does, but that in itself is not an excuse to write one. If you feel you need a comment, then write a comment.

The code itself should also be thought of as somewhat akin to English. That means you should be using proper formatting - indentation is a given, but don't be shy to put in the occasional empty line here and there to break things up into "paragraphs". It makes it much easier for the human eye to hunt down specific sections.

Bomb Bloke, on 27 December 2015 - 01:02 AM said:

HPWebcamAble, on 26 December 2015 - 10:10 PM said:

Basically, any piece of code you need to execute more than once should be a function.

Er, rather, any bit of code you want to run more than once should go into a loop; any chunk of code you want to run from more than one place should go in a function.

Right, my bad ;)/> , edited my post for clarification

MyPokeballzHurt, on 27 December 2015 - 12:55 AM said:

Also if you guys have any idea of programs I could try to make that'd be great as I don't have much ideas…

I've had the most success with games, such as othello and stacker. Nothing too fancy, but my first programs tended to be much simpler.

I made a lot of APIs when starting out, and still do. I'd advise staying away from fancy menus at first, it took me a pretty long time to figure them out. And it'd still take me a day or two to create a functional menu, without using any of my various APIs I've written for them. Many of my programs can be found on my pastebin profile, although a huge number of them were never uploaded as I felt they weren't worth the effort, or dependent upon too much user knowledge (I assume everyone running my program has no idea what they're doing).

Bomb Bloke, on 27 December 2015 - 01:02 AM said:

–snip–
Some coders like to go overboard with functions. You end up having to read their scripts bottom-to-top, because every other line they're calling a new one and so you've got to constantly scroll the page around to keep track of where the execution order's going.

And these all tend to be one-shot functions, too - called from only one place. One-shots are indeed justified if they contain a great tract of code (eg - if you have a menu, then the code for the menu itself will be a dead nuisance to read if you don't bundle its options off into functions), but their numbers should be kept to the barest minimum.

I often get the impression that people hear the line "good code doesn't need comments" and decide to cheat, putting in a new function name every time they should really just be putting in a comment. Yes, a function's name should describe what that function does, but that in itself is not an excuse to write one. If you feel you need a comment, then write a comment.

The code itself should also be thought of as somewhat akin to English. That means you should be using proper formatting - indentation is a given, but don't be shy to put in the occasional empty line here and there to break things up into "paragraphs". It makes it much easier for the human eye to hunt down specific sections.

Heh, I like to use functions to organize my code for myself, and a sometimes not worry about having to mess up, or not mess up, specific parameters and arguments passed to the function. For certain actions such as input validation, I prefer to keep that in it's own function so I can just plug and play into a different piece of code should the need ever arise.

That being said, I go a little overboard on functions, not so much as when I started but it's still a lot. As for best practice, well, less is usually more. Lua has a function stack, (some other languages have them, but C++ and Java don't really), and if you use too many functions or recursive functions, you'll crash your program pretty quickly. That in mind:

return

This little bit, the return keyword, is something you NEED to know of from the get go. I created my first large program (an over glorified door lock) and it used functions, problem is, it ran in a daisy chain sort of manner: Main,func1,func2,func3,Main etc… Thing is with functions, unless they end, either through returning or just ending out right, they stay in memory. So if you say call the print function, the program notes where it is, then zips off to run the print function, and then when that is done, comes back. What the problem with what I just showed was, Main would call func1, func1 would do stuff and then func1 would call func2 which would do stuff and call func3 which will continue doing more stuff and then finally func3 will call Main. The problem lies that func1,func2,func3,and the old Main function, are all still loaded into memory. However if I just returned (or had known of returning at the time) It would of gone down to func2 from func3, and then I would know to go back to func1, and down to Main. Once back in Main I was golden, I had what I wanted to do at the start, and I could continue using it as I wanted, and the process would repeat.

KingofGamesYami, on 27 December 2015 - 03:19 AM said:

MyPokeballzHurt, on 27 December 2015 - 12:55 AM said:

Also if you guys have any idea of programs I could try to make that'd be great as I don't have much ideas…

I've had the most success with games, such as othello and stacker. Nothing too fancy, but my first programs tended to be much simpler.

I made a lot of APIs when starting out, and still do. I'd advise staying away from fancy menus at first, it took me a pretty long time to figure them out. And it'd still take me a day or two to create a functional menu, without using any of my various APIs I've written for them. Many of my programs can be found on my pastebin profile, although a huge number of them were never uploaded as I felt they weren't worth the effort, or dependent upon too much user knowledge (I assume everyone running my program has no idea what they're doing).

Sounds very interesting and challenging (well at least for me) and I'll try it out for sure :D/>

Bomb Bloke, on 27 December 2015 - 01:02 AM said:

Most of us look at other people's scripts and think, "I would've done it like this…".

For me, "this" usually means "with more tables and loops". Don't get me wrong, you shouldn't shoe-horn in coding structures that you don't need, but most of the time a redundantly lengthy script will be that way because it's either not using loops correctly, or because it's not using tables at all.

So I guess my advice is to get familiar with for/while/repeat, and experiment with tables (nested ones in particular). Once you've got these concepts down pat you'll generally be able to write much more complex bits of code within much smaller spaces.

Creating a loop out of functions is to be avoided. If you need to loop, use one of the keywords provided specifically for the task.

HPWebcamAble, on 26 December 2015 - 10:10 PM said:

Basically, any piece of code you need to execute more than once should be a function.

Er, rather, any bit of code you want to run more than once should go into a loop; any chunk of code you want to run from more than one place should go in a function.

Some coders like to go overboard with functions. You end up having to read their scripts bottom-to-top, because every other line they're calling a new one and so you've got to constantly scroll the page around to keep track of where the execution order's going.

And these all tend to be one-shot functions, too - called from only one place. One-shots are indeed justified if they contain a great tract of code (eg - if you have a menu, then the code for the menu itself will be a dead nuisance to read if you don't bundle its options off into functions), but their numbers should be kept to the barest minimum.

I often get the impression that people hear the line "good code doesn't need comments" and decide to cheat, putting in a new function name every time they should really just be putting in a comment. Yes, a function's name should describe what that function does, but that in itself is not an excuse to write one. If you feel you need a comment, then write a comment.

The code itself should also be thought of as somewhat akin to English. That means you should be using proper formatting - indentation is a given, but don't be shy to put in the occasional empty line here and there to break things up into "paragraphs". It makes it much easier for the human eye to hunt down specific sections.

Noted, thanks!