Styleguide for Fuze
-
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
