Styleguide for Fuze
-
There is no style guide. You can do as you wish as long as you can read it and understand it. Bear in mind that if you submit it for community sharing WE also need to be able to read it too (yes, we have to read every one)
This means also that while English comments are not compulsory it would certainly be useful to us to allow us to easily check for appropriate content. Otherwise we have to use google translate to check there is no swearing in the comments!
PI is a constant too so you don’t need to define it yourself.
-
@Martin Was just an example but thanks for the quick answer.
-
Here is an example of how I do it.:
I use the Tab key all the Time to differentiate certain uses of Code
This adds readability to it.Btw I always want to initialize like that
// Globals (add your global variables between) // GlobalsThe thought behind that is to add a readable Library to your project which you can fill up Later. If a Variable is used globally of course they have to stand on top of your code.
You can add a Library for all Loaded Images as well.
//Sprites Player = Createsprite() Playerimg = Loadimage("Player") Setspriteimage(Player, Playerimg) //SpritesJust recently learned, Structs in Arrays, Arrays in Structs. Very handy if you initialize a struct like this,
struct Playerstruct int position = {0,0} Array PlayerAbilitys[3] endstruct Playerstruct Player[3]These small lines of code do really much.
I just declared an Array containing a struct which contains an Array. Everything is specific for every player.
You save a lot of lines if you do it that way, adds style and readability.Be aware that even if Arrays are dynamic there is a bug, you should always declare the size of an Array.
-
It's good to keep in mind that usually most development time is spend reading code, not writing code. On average, every line you write, you will read back lots of times. And you'll spend time thinking about what that line meant. So if you can reduce the amount of time you spend on reading and understanding that line of code, then that certainly is not a wasted effort.
I know that as a starting developer, you may be already happy when you get something to work. But if you want to learn the craft properly, I do think it's helpful to care just as much about how your code looks. Not just because it's pretty, but because it will actually help you get more done.
I don't think FUZE needs a style guide. If you have a FUZE project that multiple people are working on, then I think it's a good idea to agree with each other, for that project, how the code should be formatted. That way each developer can more easily tell how the code of other developers should be read. But for the typical FUZE project, that's really not a thing.
I'd encourage to be consistent with your formatting within your project, but I think it might even be better if you try experimenting a little with your formatting between projects. See what works, what doesn't work, and why that is so...
Consistent formatting can help developers to get more information from the code more quickly. Obviously by indenting code you can quickly see what parts of the code belong to each other. But you could also use formatting for variable names, to tell if a variable was intended to be function scoped, or global. You can think about structuring your function names in a way that helps you remember the name when you want to call it. And you could "group" functions that are related to each other with the same prefix, which would also prevent you from accidentally using the same function name twice for different things. Just to name a few examples...
On the other hand, in my opinion, too many developers tend to have too strong opinions on how the formatting should be. A good example would be the famous tabs vs spaces discussion. In the end, it's important to be consistent about indenting your code, so that it helps the developer who reads it (spoiler: that will be you). But it helps to be flexible about how the indentation happens, so that you can adapt to the rules of the project and be productive.
-
100% what PB said.
For anyone serious about improving their coding style I would highly recommend the book "Clean Code: A Handbook of Agile Software Craftsmanship" by Robert C. Martin.
That might sound highly technical but it's really just the "Clean Code" part of the title that's the point; it's not about "Agile".
A few points about it:
- It's probably not something a brand new programmer should read until they have a little bit of coding experience (I'm talking weeks not years.)
- He does tend to go to the extreme with his refactoring sometimes, but you can find a middle ground of what works for you.
- The code examples are in Java but it's not a book about writing Java. Anyone with a moderate amount of experience with Fuze would be able to follow them.
Also, just to be clear, I have no affiliation with this book or its author, I just think it's a book that every software developer should read.
-
Thanks for all this comments
I also would mention again I dont want to force anyone in a special style direction do it your way if you want 1 line if statements do it I also made it in the past
-
I think it's useful if you format your code once you finished the segment of code and debugged it. If thens are heavy to read anyway depending on length. I would just comment the line below just to know what's written there.
-
Sure, sometimes it's more practical to put if statements on one line as well.
In my Solitaire game I have a function called command_lock that makes sure that a struct only has a true value for a type of input if it is the first frame where that input is true. It has a whole batch of if statements that do basically the same thing, but for each type of input (pseudo:
if pressed != wasPressed then values.pressed = pressed else values.pressed = false endif). Since all those if statements need to do the exact type of check bug for different inputs, I found it more practical to make them one line.
That way they all fit on my screen and I can spot incorrect differences more easily (since each line needs to check for one specific type of input).So in on one hand I say be consistent, but on the other hand, sometimes making an exception might be what you want. (if the language would have reflective features to iterate the properties of a struct dynamically, I would choose a different solution though, but that's not something I'd ask of the fuze language :) )
-
@petermeisenstein said in Styleguide for Fuze:
I also would mention again I dont want to force anyone in a special style direction do it your way if you want 1 line if statements do it I also made it in the past
There is absolutely nothing wrong with a 1 line ‘if statement’ as long as it is not excessively long. In fact, splitting out a trivial 1 line if statement into 3 lines can sometime just be long winded and clutter things up for the sake of it whilst serving no real purpose.
You need to make your own judgement and get into your own style and groove.
I’m old enough to remember when carriage return (linefeed) cost memory you couldn’t afford to waste.
-
I'm old enough to remember when you had to write your own key scanning code using a 6255 pio at £8 a time (they were always going pop!) and a Radio Shack matrix keyboard for $49. Trying to figure out the double debounce code was the biggest problem. All in 1K of ram. 4k was about £100. We're talking around 1978-79. Happy days - maybe not ,,,
-
@faz808 Wasnt a pc in the end of the 70s very expensive?
-
This is worth a read. And yes, a pc was expensive in the 70's.
http://www.lighterra.com/articles/historyofcomputers/1970s.html
I soldered scores of TTL chips on veroboard and dozens1N4148 diodes on a homemade keyboard just to display text on a tv screen ! Practical Electronics was my bible. -
@PB____ i really like this post and it has made me think about how i set out my code, one small example i tab out most of my code but when working on say a location or multiple locations i move them to the margin so i know where im at.
-
@waldron the good thing is that fuze gives you freedom in your style
