What are some tips you would give Developers to make code less messy? And what do you think are some of the most common mistakes? And how do you not make typos (one of the major cause of errors)? I’m asking this because I know a lot of Devs could use your tips to make their code more readable, thanks in advance for any tips you give!
My Tips
Tip 1: Add blank lines between arguments
Tip 2: Make variables names descriptive
Tip 3: Don’t mix camelCase, PascalCase and Loud_Snake
Why repost
I made thsi repost because the old topic got flagged, it was flagged because there was only the first question (I had to run, so I didn’t have much time) and it got flagged, I tried to contact the moderators to unlock the topic but they seem to not answer…
For the love of god, please use Module Scripts, They’ve helped me massively with my experience after I made a 622 line client-side script for handling several basic tasks.
Edit: It was the dumbest thing that I have ever done.
Proper planning, if you don’t know what your code is, its going to be really messy and inefficient. Once that code is bug-free just copy the principles into a neat design
That’s only useful if you’ve got a dev team, but really if you didn’t abbreviate things everyone would be able to understand it (a small exception goes for extremely advanced systems). If you can’t remember what your code does then I don’t know what to say to ya.
For those of who that don’t know what to do with Module Scripts, use them for shortening code! For an example, if you have a server script with a player added event in it, you could make a Module Script only for the CharacterAdded event. It makes your game easier to work on.
The most important use for Module Scripts is sharing code though.
Yes but there’s also a lot do #development-discussion tipics that ask question! Why are those not flagged! Why are this okay and mine not! Also if you have a more suitable category than just say it and I’ll move it there
Here is the primary axiom of clean code as far as the individual script goes: code should read like plain english. No one knows what a blarg18264672 is, don’t name your variable that. No one knows what “((x % 5== 0 and x % 3==0) and “fizz buzz”) or (x % 5 == 0 and “buzz”) or (x % 3 == 0 and “fizz”) or x” means. Don’t try to be cryptic to be supr mega hacer!!1!. Don’t try to show off with hacky stuff. Write your code so that your coworkers won’t want to cry when they have to fix your script down the line.
As for overall organization, think of your codebase like an instruction manual (after all, that’s what it is). Have a different set of instructions for each thing (each script/class/method/function should perform one task/serve one urpose), break up your instructions in a logical manner consistent throughout your instruction manual (i.e. using folders), and you’re golden.
Some tips:
Code should be self explanatory without the need for many comments.
a. Bad comments explain what the code does.
b. Good comments might explain why the code does it, or give instructions for how to use the code in other parts of the codebase.
Try not to have more than 80 columns per line. Never go over 120. Humans read in portrait mode, not in landscape mode.
Use module scripts and multiscript architecture to adhere to the separation of concerns principle.
Be very wary of coupling and cohesion in your codebase. Not managing this properly will come back to bite you on larger projects.
Choose a style format for code and stick to it.
Choose an organization format for files and stick to it.
Use accurate, descriptive names.
Use whatever paradigm (i.e. OOP, procedural, functional) that fits the job. OOP is a good way to organize some tasks, but it isn’t a good way to organize others. You have to make that judgment.
Break up complex logic into steps and perhaps even use parenthesis for grouping so that it can be read by a human. For instance,
-- You cannot read this
-- (if you can but you spent more than 10 seconds trying then it doesn't count)
((x % 5== 0 and x % 3==0) and "fizz buzz") or (x % 5 == 0 and "buzz") or (x % 3 == 0 and "fizz") or x
-- You can read this
local IsDivisibleBy3 = (x % 3 == 0) -- Parentheses optional, but I like them here to sort of break apart the "=" from the "==" a bit and thus make it more quickly understandable that the boolean statement is its own unit
local IsDivisibleBy5 = (x % 5 == 0)
local Word =
if (IsDivisibleBy3 and IsDivisibleBy5) then "fizzbuzz" -- Again, parentheses optional, but I use them here again for the same reason as before.
elseif IsDivisibleBy3 then"fizz"
elseif IsDivisibleBy5 then "buzz"
else x
Each function should perform one task. Even if that one thing is running a bunch of other functions that each do one thing to perform one larger task, that’s worlds better than having a 500 line function that does many things.
Be concise inasmuch as it helps readability.
Code should be boring. If theres a hacky but cool way to do it or a boring but readable way to do it, do the boring but readable way. As someone who works with other scripters, I hate having to wade through hacky code that some doofus wrote all hopped up on Linus Tech Tips and Mr. Robot episodes, but I love clear, normal, plain english instructions. As a development lead on a small project between my friends and me, “cool!1!” code for the sake of showing off doesn’t impress me and won’t get anyone hired. Clean, readable code will.
Don’t repeat yourself, Write modules or functions for boilerplate code.
Fail fast. If there’s an edge case in a function, don’t just return nil if the code shouldn’t have a nil value for that task. Instead, throw an error.
Don’t microoptimize at the cost of readability. It’s stupid. Readability is the priority. Millimillimillimilliseconds of run time don’t matter, but hours and hours wasted trying to read your code to debug it do matter.
Try not to use more than 3 blocks of indentation. This isn’t a hard limit, but it’s a good goal. We read from left to right. As such, it’s easier to read when your text starts on the left side of your screen and not way over on the other side where your eyes will never naturally rest. Guard clauses help a ton with this.
Except in the case of guard clauses - and even that’s debatable - one statement per line is a good rule to adhere to. Many easily understandable lines are better than fewer confusing lines if it does the exact same thing.
BE. CONSISTENT. Don’t do one thing one way and then do the same thing a different way later. That’s a recipe for confusion.
For more learning:
For how to organize your code, check out refactoring.guru. It just has everything man. From design pattern explanations to clean code tips to anything you can imagine to get your codebase in tip top shape. It’s an amazing learning resource and you can learn something new every time you visit it.
CodeAesthetic on youtube explains stuff fairly intuitively and nicely, in almost a 3blue1brown-esque style. He doesn’t have many videos yet, though.
