How should code look?

There’s no right or wrong way to format your code (especially if it’s just you looking at it) but indents make it more readable and easier for the eye to follow which is handy for troubleshooting, etc.

INPUT “HELLO” HELLO$

IF HELLO$=“hello” THEN
 PRINT “good to see you”
ELSEIF HELLO$==“hi” THEN
 PRINT “how are ya”
ELSE
 ...
ENDIF

Ideally, if conditions/results can fit on one line, I would do that, but if the result of a condition is lengthy than I would indent it under the condition. I also indent code within a loop and DEFs.

There is a right and a wrong way to format your code. kitesinpowerlines above did a good job of reformatting your original code. There are programmer "Holy Wars" on the subject of if you use Tabs or spaces. Either way you do want to format your code. If you go into programming as a career you will spend most of your time maintaining someone else's code. You want whoever wrote the code to make it easy to read, understand and modify. That is why you should use plenty of comments too. Even if you are a one-man-team and write everything yourself, it won't take long before you curse your younger self for not formatting things well. While SmileBasic doesn't have any, It is common enough that there are automated code formatting utilities. I remember using Meta-x indent-selection in emacs and have prettier setup in Angular. People spend a good lot of time on this and I am glad you picked up on it; it says good things about you. Over on the Fuze4Switch site they had a call for entries for their Fuze Player demo application and had code formatting demands (excerpt below). Keep in mind they weren't paying you anything and still demanded code formatting. https://fuzearena.com/forum/topic/921/fuze-player-project-submission-important-information

• It should be commented throughout and provide explanations for key functions.
• Comments and explanations must be in English. We are very happy to help the creator to make this possible.
• It should use relevant variable and function names where possible. This is not to say we will only accept player_x_axis_position += player_x_axis_velocity, something like plrPos += plrVel is fine.
• To be clear - we want to avoid instances of random or completely unrelated variable names. For single-letter variables that aren't standard (x or y for example) or slightly more cryptic variable names, this will be accepted if there is sufficient explanation in a comment.
• It should be well spaced and use either tabs or 2 spaces to indent loops, conditional statements and function definitions.

As mentioned in their list good variable names are also important. No one is going to get after you for using x, y for a location on the screen or i for an index into a string or array but you can have fairly long names and should make use of the ability. Using c for the number of cats in a room will get you in trouble with your boss, you should use something like countCats instead. There are several conventions on how to name variables too (camelCase, PascalCase, and snake_case). In fact which you use might depend on what kind of thing you are naming. Lastly I have to address the elephant in the room. Line numbers. You don't need them and shouldn't be using them outside of a RESTORE statement, and even then you should use line labels instead. If you are using GOTO/GOSUB you need to learn about functions. Functions are much much better, and are there to help. If you are using a book on BASIC from the 80s as a reference it might be more harm than help.

About indentation, the SB editor doesn't support tabs (you can use them, but they're just rendered as a blue → symbol, and there's no tab key on the onscreen keyboard (I think a USB keyboard will just insert spaces)) Most people use 1 (sometimes 2) spaces for indentation, (since SB uses a very wide font, this is closer to what a tab width of 2 (or 4) would look like, in most other editors) Automatic indentation tool: https://smilebasicsource.com/page?pid=182 If you're using SB3 (or SB4 without a USB keyboard), I would recommend using shorter variable names than usual, because of the very small screen size, and the onscreen keyboard Something like "countCats" will take a while to type and your lines will quickly end up being much wider than the screen

I suppose I was considering naming and formatting in a more generic sense. SmileBasic does have its own set of gotcha's due to the small screen and on-screen keyboard. The good news is that the formatting is pretty consistent among languages and platforms.

I have a question about this: what about spaces between lines? Is there any rule about this? What I’ve been doing is putting comments between steps in algorithms, and putting empty lines between functions. Is there a better way, or is the way I’m doing it fine?