This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
crpl:styleguide [2015/03/28 18:16] – created warren | crpl:styleguide [2025/02/14 14:57] (current) – external edit 127.0.0.1 | ||
---|---|---|---|
Line 1: | Line 1: | ||
====== Style guide ====== | ====== Style guide ====== | ||
- | There are several basic rules that should be followed when writing code, in CRPL, or in any other language: | + | There are several basic rules that should be followed when writing code, in CRPL, or in any other language. This list is sorted in descending order of importance. |
#1: Style is optional. It is only ever required when sharing code with others, such as when posting examples on the wiki. There is nothing wrong with creating your own style, either, so long as your team mates agree. | #1: Style is optional. It is only ever required when sharing code with others, such as when posting examples on the wiki. There is nothing wrong with creating your own style, either, so long as your team mates agree. | ||
Line 173: | Line 173: | ||
</ | </ | ||
- | A rule of thumb is there are one to five lines in a paragraph. Each paragraph must have its own story, the lines int the paragraph united in a single mission. An optional practice is to place a comment at the head of each paragraph, explicitly stating this common purpose: | + | A rule of thumb is there are one to five lines in a paragraph. Each paragraph must have its own story, the lines in the paragraph united in a single mission. An optional practice is to place a comment at the head of each paragraph, explicitly stating this common purpose: |
< | < | ||
Line 241: | Line 241: | ||
:awake | :awake | ||
- | once | + | |
- | PI 2 mul -> | + | PI 2 mul -> |
- | 0 -> | + | 0 -> |
- | endonce | + | endonce |
</ | </ | ||
Line 263: | Line 263: | ||
#6 Read code with a fixed width font. This ensures that what you see is common across different machines and contexts. If you add examples to the wiki, surround with %%< | #6 Read code with a fixed width font. This ensures that what you see is common across different machines and contexts. If you add examples to the wiki, surround with %%< | ||
+ | #7 Any paragraph or line or even subsection of a line that occurs more than once might make a good function. Go through your code and look for patterns and repetition at various scales. If you spot two very similar paragraphs think about how they would need to change to become identical. If it is simple, consider making a new function. The more often it occurs, the cleaner function extraction will make the code. | ||
+ | #8 Precalculate stuff. Go through your code looking for patterns or repetition at various scales. If you calculate the same number twice, consider calculating it earlier, and putting it in a variable. In addition, if you pull a calculation out of a loop, the code usually becomes faster. | ||
+ | ==== Exceptions to rule #2 ==== | ||
+ | Too much indenting can squish the code to the right and hinder readability. In addition to putting the body of a heavily nested loop into its own function, there is a special rule that can be used. | ||
+ | |||
+ | If else chains: | ||
+ | < | ||
+ | #play sound: silence 50%probability | ||
+ | # weapons15 33%probability | ||
+ | # explosion4 11%probability | ||
+ | # weapons18 6%probability | ||
+ | 0 18 RandInt ->temp | ||
+ | <-temp eq0 if | ||
+ | " | ||
+ | else <-temp 3 lt if | ||
+ | " | ||
+ | else <-temp 9 lt if | ||
+ | " | ||
+ | endif endif endif endif | ||
+ | </ | ||
+ | |||
+ | This is similar to case statements available in other languages and elseif statements in yet others. | ||