xref: /aosp_15_r20/external/google-styleguide/vimscriptguide.xml (revision 8c35d5ee8e2913d4bd6623e2b93232b1da0ab719) 
1*8c35d5eeSXin Li<?xml version = '1.0'?>
2*8c35d5eeSXin Li<?xml-stylesheet type="text/xsl" href="styleguide.xsl"?>
3*8c35d5eeSXin Li<GUIDE title="Google Vimscript Style Guide">
4*8c35d5eeSXin Li  <p class="revision">
5*8c35d5eeSXin Li
6*8c35d5eeSXin Li    Revision 1.1
7*8c35d5eeSXin Li  </p>
8*8c35d5eeSXin Li
9*8c35d5eeSXin Li
10*8c35d5eeSXin Li  <address>
11*8c35d5eeSXin Li    Nate Soares<br/>
12*8c35d5eeSXin Li    Joshua Hoak<br/>
13*8c35d5eeSXin Li    David Barnett<br/>
14*8c35d5eeSXin Li  </address>
15*8c35d5eeSXin Li
16*8c35d5eeSXin Li  <OVERVIEW>
17*8c35d5eeSXin Li    <CATEGORY title="Background">
18*8c35d5eeSXin Li      <p>
19*8c35d5eeSXin Li        This is a casual version of the vimscript style guide, because
20*8c35d5eeSXin Li        vimscript is a casual language. When submitting vim plugin code, you
21*8c35d5eeSXin Li        must adhere to these rules. For clarifications, justifications, and
22*8c35d5eeSXin Li        explanations about the finer points of vimscript, please refer to the
23*8c35d5eeSXin Li        <a href="vimscriptfull.xml">heavy guide</a>.
24*8c35d5eeSXin Li      </p>
25*8c35d5eeSXin Li    </CATEGORY>
26*8c35d5eeSXin Li  </OVERVIEW>
27*8c35d5eeSXin Li
28*8c35d5eeSXin Li  <CATEGORY title="Portability">
29*8c35d5eeSXin Li    <p>
30*8c35d5eeSXin Li      It's hard to get vimscript right. Many commands depend upon the user's
31*8c35d5eeSXin Li      settings. By following these guidelines, you can hope to make your
32*8c35d5eeSXin Li      scripts portable.
33*8c35d5eeSXin Li    </p>
34*8c35d5eeSXin Li    <STYLEPOINT title="Strings">
35*8c35d5eeSXin Li      <SUMMARY>Prefer single quoted strings</SUMMARY>
36*8c35d5eeSXin Li      <BODY>
37*8c35d5eeSXin Li        <p>
38*8c35d5eeSXin Li          Double quoted strings are semantically different in vimscript, and
39*8c35d5eeSXin Li          you probably don't want them (they break regexes).
40*8c35d5eeSXin Li        </p>
41*8c35d5eeSXin Li        <p>
42*8c35d5eeSXin Li          Use double quoted strings when you need an escape sequence (such as
43*8c35d5eeSXin Li          <code>"\n"</code>) or if you know it doesn't matter and you need to
44*8c35d5eeSXin Li          embed single quotes.
45*8c35d5eeSXin Li        </p>
46*8c35d5eeSXin Li      </BODY>
47*8c35d5eeSXin Li    </STYLEPOINT>
48*8c35d5eeSXin Li    <STYLEPOINT title="Matching Strings">
49*8c35d5eeSXin Li      <SUMMARY>
50*8c35d5eeSXin Li        Use the <code>=~#</code> or <code>=~?</code> operator families over the
51*8c35d5eeSXin Li        <code>=~</code> family.
52*8c35d5eeSXin Li      </SUMMARY>
53*8c35d5eeSXin Li      <BODY>
54*8c35d5eeSXin Li        <p>
55*8c35d5eeSXin Li          The matching behavior depends upon the user's ignorecase and smartcase
56*8c35d5eeSXin Li          settings and on whether you compare them with the <code>=~</code>,
57*8c35d5eeSXin Li          <code>=~#</code>, or <code>=~?</code> family of operators. Use the
58*8c35d5eeSXin Li          <code>=~#</code> and <code>=~?</code> operator families explicitly
59*8c35d5eeSXin Li          when comparing strings unless you explicitly need to honor the user's
60*8c35d5eeSXin Li          case sensitivity settings.
61*8c35d5eeSXin Li        </p>
62*8c35d5eeSXin Li      </BODY>
63*8c35d5eeSXin Li    </STYLEPOINT>
64*8c35d5eeSXin Li    <STYLEPOINT title="Regular Expressions">
65*8c35d5eeSXin Li      <SUMMARY>Prefix all regexes with <code>\m\C</code>.</SUMMARY>
66*8c35d5eeSXin Li      <BODY>
67*8c35d5eeSXin Li        <p>
68*8c35d5eeSXin Li          In addition to the case sensitivity settings, regex behavior depends
69*8c35d5eeSXin Li          upon the user's nomagic setting. To make regexes act like nomagic and
70*8c35d5eeSXin Li          noignorecase are set, prepend all regexes with <code>\m\C</code>.
71*8c35d5eeSXin Li        </p>
72*8c35d5eeSXin Li        <p>
73*8c35d5eeSXin Li          You are welcome to use other magic levels (<code>\v</code>) and case
74*8c35d5eeSXin Li          sensitivities (<code>\c</code>) so long as they are intentional and
75*8c35d5eeSXin Li          explicit.
76*8c35d5eeSXin Li        </p>
77*8c35d5eeSXin Li      </BODY>
78*8c35d5eeSXin Li    </STYLEPOINT>
79*8c35d5eeSXin Li    <STYLEPOINT title="Dangerous commands">
80*8c35d5eeSXin Li      <SUMMARY>Avoid commands with unintended side effects.</SUMMARY>
81*8c35d5eeSXin Li      <BODY>
82*8c35d5eeSXin Li        <p>
83*8c35d5eeSXin Li          Avoid using <code>:s[ubstitute]</code> as it moves the cursor and
84*8c35d5eeSXin Li          prints error messages. Prefer functions (such as
85*8c35d5eeSXin Li          <code>search()</code>) better suited to scripts.
86*8c35d5eeSXin Li        </p>
87*8c35d5eeSXin Li        <p>
88*8c35d5eeSXin Li          For many vim commands, functions exist that do the same thing with
89*8c35d5eeSXin Li          fewer side effects. See <code>:help functions()</code> for a list of
90*8c35d5eeSXin Li          built-in functions.
91*8c35d5eeSXin Li        </p>
92*8c35d5eeSXin Li      </BODY>
93*8c35d5eeSXin Li    </STYLEPOINT>
94*8c35d5eeSXin Li    <STYLEPOINT title="Fragile commands">
95*8c35d5eeSXin Li      <SUMMARY>Avoid commands that rely on user settings.</SUMMARY>
96*8c35d5eeSXin Li      <BODY>
97*8c35d5eeSXin Li        <p>
98*8c35d5eeSXin Li          Always use <code>normal!</code> instead of <code>normal</code>. The
99*8c35d5eeSXin Li          latter depends upon the user's key mappings and could do anything.
100*8c35d5eeSXin Li        </p>
101*8c35d5eeSXin Li        <p>
102*8c35d5eeSXin Li          Avoid <code>:s[ubstitute]</code>, as its behavior depends upon a
103*8c35d5eeSXin Li          number of local settings.
104*8c35d5eeSXin Li        </p>
105*8c35d5eeSXin Li        <p>
106*8c35d5eeSXin Li          The same applies to other commands not listed here.
107*8c35d5eeSXin Li        </p>
108*8c35d5eeSXin Li      </BODY>
109*8c35d5eeSXin Li    </STYLEPOINT>
110*8c35d5eeSXin Li    <STYLEPOINT title="Catching Exceptions">
111*8c35d5eeSXin Li      <SUMMARY>Match error codes, not error text.</SUMMARY>
112*8c35d5eeSXin Li      <BODY>
113*8c35d5eeSXin Li        <p>Error text may be locale dependant.</p>
114*8c35d5eeSXin Li      </BODY>
115*8c35d5eeSXin Li    </STYLEPOINT>
116*8c35d5eeSXin Li  </CATEGORY>
117*8c35d5eeSXin Li
118*8c35d5eeSXin Li  <CATEGORY title="General Guidelines">
119*8c35d5eeSXin Li
120*8c35d5eeSXin Li
121*8c35d5eeSXin Li    <STYLEPOINT title="Messaging">
122*8c35d5eeSXin Li      <SUMMARY>Message the user infrequently.</SUMMARY>
123*8c35d5eeSXin Li      <BODY>
124*8c35d5eeSXin Li        <p>
125*8c35d5eeSXin Li          Loud scripts are annoying. Message the user only when:
126*8c35d5eeSXin Li          <ul>
127*8c35d5eeSXin Li            <li>A long-running process has kicked off.</li>
128*8c35d5eeSXin Li            <li>An error has occurred.</li>
129*8c35d5eeSXin Li          </ul>
130*8c35d5eeSXin Li        </p>
131*8c35d5eeSXin Li      </BODY>
132*8c35d5eeSXin Li    </STYLEPOINT>
133*8c35d5eeSXin Li    <STYLEPOINT title="Type checking">
134*8c35d5eeSXin Li      <SUMMARY>Use strict and explicit checks where possible.</SUMMARY>
135*8c35d5eeSXin Li      <BODY>
136*8c35d5eeSXin Li        <p>
137*8c35d5eeSXin Li          Vimscript has unsafe, unintuitive behavior when dealing with some
138*8c35d5eeSXin Li          types. For instance, <code>0 == 'foo'</code> evaluates to true.
139*8c35d5eeSXin Li        </p>
140*8c35d5eeSXin Li        <p>
141*8c35d5eeSXin Li          Use strict comparison operators where possible. When comparing against
142*8c35d5eeSXin Li          a string literal, use the <code>is#</code> operator. Otherwise, prefer
143*8c35d5eeSXin Li          <code>maktaba#value#IsEqual</code> or check <code>type()</code>
144*8c35d5eeSXin Li          explicitly.
145*8c35d5eeSXin Li        </p>
146*8c35d5eeSXin Li        <p>
147*8c35d5eeSXin Li          Check variable types explicitly before using them. Use functions from
148*8c35d5eeSXin Li          <code>maktaba#ensure</code>, or check <code>maktaba#value</code> or
149*8c35d5eeSXin Li          <code>type()</code> and throw your own errors.
150*8c35d5eeSXin Li        </p>
151*8c35d5eeSXin Li        <p>
152*8c35d5eeSXin Li          Use <code>:unlet</code> for variables that may change types,
153*8c35d5eeSXin Li          particularly those assigned inside loops.
154*8c35d5eeSXin Li        </p>
155*8c35d5eeSXin Li      </BODY>
156*8c35d5eeSXin Li    </STYLEPOINT>
157*8c35d5eeSXin Li    <STYLEPOINT title="Python">
158*8c35d5eeSXin Li      <SUMMARY>Use sparingly.</SUMMARY>
159*8c35d5eeSXin Li      <BODY>
160*8c35d5eeSXin Li        <p>
161*8c35d5eeSXin Li          Use python only when it provides critical functionality, for example
162*8c35d5eeSXin Li          when writing threaded code.
163*8c35d5eeSXin Li        </p>
164*8c35d5eeSXin Li      </BODY>
165*8c35d5eeSXin Li    </STYLEPOINT>
166*8c35d5eeSXin Li    <STYLEPOINT title="Other Languages">
167*8c35d5eeSXin Li      <SUMMARY>Use vimscript instead.</SUMMARY>
168*8c35d5eeSXin Li      <BODY>
169*8c35d5eeSXin Li        <p>
170*8c35d5eeSXin Li          Avoid using other scripting languages such as ruby and lua. We can
171*8c35d5eeSXin Li          not guarantee that the end user's vim has been compiled with support
172*8c35d5eeSXin Li          for non-vimscript languages.
173*8c35d5eeSXin Li        </p>
174*8c35d5eeSXin Li      </BODY>
175*8c35d5eeSXin Li    </STYLEPOINT>
176*8c35d5eeSXin Li    <STYLEPOINT title="Boilerplate">
177*8c35d5eeSXin Li      <SUMMARY>
178*8c35d5eeSXin Li        Use <a href="https://github.com/google/maktaba">maktaba</a>.
179*8c35d5eeSXin Li      </SUMMARY>
180*8c35d5eeSXin Li      <BODY>
181*8c35d5eeSXin Li        <p>
182*8c35d5eeSXin Li          maktaba removes boilerplate, including:
183*8c35d5eeSXin Li          <ul>
184*8c35d5eeSXin Li            <li>Plugin creation</li>
185*8c35d5eeSXin Li            <li>Error handling</li>
186*8c35d5eeSXin Li            <li>Dependency checking</li>
187*8c35d5eeSXin Li          </ul>
188*8c35d5eeSXin Li        </p>
189*8c35d5eeSXin Li      </BODY>
190*8c35d5eeSXin Li    </STYLEPOINT>
191*8c35d5eeSXin Li    <STYLEPOINT title="Plugin layout">
192*8c35d5eeSXin Li      <SUMMARY>Organize functionality into modular plugins</SUMMARY>
193*8c35d5eeSXin Li      <BODY>
194*8c35d5eeSXin Li        <p>
195*8c35d5eeSXin Li          Group your functionality as a plugin, unified in one directory (or
196*8c35d5eeSXin Li          code repository) which shares your plugin's name (with a "vim-" prefix
197*8c35d5eeSXin Li          or ".vim" suffix if desired). It should be split into plugin/,
198*8c35d5eeSXin Li          autoload/, etc. subdirectories as necessary, and it should declare
199*8c35d5eeSXin Li          metadata in the addon-info.json format (see the
200*8c35d5eeSXin Li          <a href="https://github.com/MarcWeber/vim-addon-manager/blob/master/doc/vim-addon-manager-additional-documentation.txt">VAM documentation</a> for details).
201*8c35d5eeSXin Li        </p>
202*8c35d5eeSXin Li      </BODY>
203*8c35d5eeSXin Li    </STYLEPOINT>
204*8c35d5eeSXin Li    <STYLEPOINT title="Functions">
205*8c35d5eeSXin Li      <SUMMARY>
206*8c35d5eeSXin Li        In the autoload/ directory, defined with <code>[!]</code> and
207*8c35d5eeSXin Li        <code>[abort]</code>.
208*8c35d5eeSXin Li      </SUMMARY>
209*8c35d5eeSXin Li      <BODY>
210*8c35d5eeSXin Li        <p>
211*8c35d5eeSXin Li          Autoloading allows functions to be loaded on demand, which makes
212*8c35d5eeSXin Li          startuptime faster and enforces function namespacing.
213*8c35d5eeSXin Li        </p>
214*8c35d5eeSXin Li        <p>
215*8c35d5eeSXin Li          Script-local functions are welcome, but should also live in autoload/
216*8c35d5eeSXin Li          and be called by autoloaded functions.
217*8c35d5eeSXin Li        </p>
218*8c35d5eeSXin Li        <p>
219*8c35d5eeSXin Li          Non-library plugins should expose commands instead of functions.
220*8c35d5eeSXin Li          Command logic should be extracted into functions and autoloaded.
221*8c35d5eeSXin Li        </p>
222*8c35d5eeSXin Li        <p>
223*8c35d5eeSXin Li          <code>[!]</code> allows developers to reload their functions
224*8c35d5eeSXin Li          without complaint.
225*8c35d5eeSXin Li        </p>
226*8c35d5eeSXin Li        <p>
227*8c35d5eeSXin Li          <code>[abort]</code> forces the function to halt when it encounters
228*8c35d5eeSXin Li          an error.
229*8c35d5eeSXin Li        </p>
230*8c35d5eeSXin Li      </BODY>
231*8c35d5eeSXin Li    </STYLEPOINT>
232*8c35d5eeSXin Li    <STYLEPOINT title="Commands">
233*8c35d5eeSXin Li      <SUMMARY>
234*8c35d5eeSXin Li        In the plugin/commands.vim or under the ftplugin/ directory, defined
235*8c35d5eeSXin Li        without <code>[!]</code>.
236*8c35d5eeSXin Li      </SUMMARY>
237*8c35d5eeSXin Li      <BODY>
238*8c35d5eeSXin Li        <p>
239*8c35d5eeSXin Li          General commands go in <code>plugin/commands.vim</code>.
240*8c35d5eeSXin Li          Filetype-specific commands go in <code>ftplugin/</code>.
241*8c35d5eeSXin Li        </p>
242*8c35d5eeSXin Li        <p>
243*8c35d5eeSXin Li          Excluding <code>[!]</code> prevents your plugin from silently
244*8c35d5eeSXin Li          clobbering existing commands.  Command conflicts should be resolved by
245*8c35d5eeSXin Li          the user.
246*8c35d5eeSXin Li        </p>
247*8c35d5eeSXin Li      </BODY>
248*8c35d5eeSXin Li    </STYLEPOINT>
249*8c35d5eeSXin Li    <STYLEPOINT title="Autocommands">
250*8c35d5eeSXin Li      <SUMMARY>
251*8c35d5eeSXin Li        Place them in plugin/autocmds.vim, within augroups.
252*8c35d5eeSXin Li      </SUMMARY>
253*8c35d5eeSXin Li      <BODY>
254*8c35d5eeSXin Li        <p>
255*8c35d5eeSXin Li          Place all autocommands in augroups.
256*8c35d5eeSXin Li        </p>
257*8c35d5eeSXin Li        <p>
258*8c35d5eeSXin Li          The augroup name should be unique. It should either be, or be prefixed
259*8c35d5eeSXin Li          with, the plugin name.
260*8c35d5eeSXin Li        </p>
261*8c35d5eeSXin Li        <p>
262*8c35d5eeSXin Li          Clear the augroup with <code>autocmd!</code> before defining new
263*8c35d5eeSXin Li          autocommands in the augroup. This makes your plugin re-entrable.
264*8c35d5eeSXin Li        </p>
265*8c35d5eeSXin Li      </BODY>
266*8c35d5eeSXin Li    </STYLEPOINT>
267*8c35d5eeSXin Li    <STYLEPOINT title="Mappings">
268*8c35d5eeSXin Li      <SUMMARY>
269*8c35d5eeSXin Li        Place them in <code>plugin/mappings.vim</code>, using
270*8c35d5eeSXin Li        <code>maktaba#plugin#MapPrefix</code> to get a prefix.
271*8c35d5eeSXin Li      </SUMMARY>
272*8c35d5eeSXin Li      <BODY>
273*8c35d5eeSXin Li        <p>
274*8c35d5eeSXin Li          All key mappings should be defined in
275*8c35d5eeSXin Li          <code>plugin/mappings.vim</code>.
276*8c35d5eeSXin Li        </p>
277*8c35d5eeSXin Li        <p>
278*8c35d5eeSXin Li          Partial mappings (see :help using-&lt;Plug&gt;.) should be defined in
279*8c35d5eeSXin Li          <code>plugin/plugs.vim</code>.
280*8c35d5eeSXin Li        </p>
281*8c35d5eeSXin Li      </BODY>
282*8c35d5eeSXin Li    </STYLEPOINT>
283*8c35d5eeSXin Li    <STYLEPOINT title="Settings">
284*8c35d5eeSXin Li      <SUMMARY>Change settings locally</SUMMARY>
285*8c35d5eeSXin Li      <BODY>
286*8c35d5eeSXin Li        <p>
287*8c35d5eeSXin Li          Use <code>:setlocal</code> and <code>&amp;l:</code> instead of
288*8c35d5eeSXin Li          <code>:set</code> and <code>&amp;</code> unless you have explicit
289*8c35d5eeSXin Li          reason to do otherwise.
290*8c35d5eeSXin Li        </p>
291*8c35d5eeSXin Li      </BODY>
292*8c35d5eeSXin Li    </STYLEPOINT>
293*8c35d5eeSXin Li  </CATEGORY>
294*8c35d5eeSXin Li
295*8c35d5eeSXin Li  <CATEGORY title="Style">
296*8c35d5eeSXin Li    <p>
297*8c35d5eeSXin Li      Follow google style conventions. When in doubt, treat vimscript style
298*8c35d5eeSXin Li      like python style.
299*8c35d5eeSXin Li    </p>
300*8c35d5eeSXin Li
301*8c35d5eeSXin Li    <STYLEPOINT title="Whitespace">
302*8c35d5eeSXin Li      <SUMMARY>
303*8c35d5eeSXin Li        Similar to python.
304*8c35d5eeSXin Li
305*8c35d5eeSXin Li        <br/>
306*8c35d5eeSXin Li        <br/>
307*8c35d5eeSXin Li      </SUMMARY>
308*8c35d5eeSXin Li      <BODY>
309*8c35d5eeSXin Li        <ul>
310*8c35d5eeSXin Li          <li>Use two spaces for indents</li>
311*8c35d5eeSXin Li          <li>Do not use tabs</li>
312*8c35d5eeSXin Li          <li>Use spaces around operators
313*8c35d5eeSXin Li            <p>This does not apply to arguments to commands.</p>
314*8c35d5eeSXin Li            <CODE_SNIPPET>
315*8c35d5eeSXin Li              let s:variable = "concatenated " . "strings"
316*8c35d5eeSXin Li              command -range=% MyCommand
317*8c35d5eeSXin Li            </CODE_SNIPPET>
318*8c35d5eeSXin Li          </li>
319*8c35d5eeSXin Li          <li>Do not introduce trailing whitespace
320*8c35d5eeSXin Li            <p>You need not go out of your way to remove it.</p>
321*8c35d5eeSXin Li            <p>
322*8c35d5eeSXin Li              Trailing whitespace is allowed in mappings which prep commands
323*8c35d5eeSXin Li              for user input, such as
324*8c35d5eeSXin Li              "<code>noremap &lt;leader&gt;gf :grep -f </code>".
325*8c35d5eeSXin Li            </p>
326*8c35d5eeSXin Li          </li>
327*8c35d5eeSXin Li          <li>Restrict lines to 80 columns wide</li>
328*8c35d5eeSXin Li          <li>Indent continued lines by four spaces</li>
329*8c35d5eeSXin Li          <li>Do not align arguments of commands
330*8c35d5eeSXin Li            <BAD_CODE_SNIPPET>
331*8c35d5eeSXin Li              command -bang MyCommand  call myplugin#foo()
332*8c35d5eeSXin Li              command       MyCommand2 call myplugin#bar()
333*8c35d5eeSXin Li            </BAD_CODE_SNIPPET>
334*8c35d5eeSXin Li            <CODE_SNIPPET>
335*8c35d5eeSXin Li              command -bang MyCommand call myplugin#foo()
336*8c35d5eeSXin Li              command MyCommand2 call myplugin#bar()
337*8c35d5eeSXin Li            </CODE_SNIPPET>
338*8c35d5eeSXin Li          </li>
339*8c35d5eeSXin Li        </ul>
340*8c35d5eeSXin Li      </BODY>
341*8c35d5eeSXin Li    </STYLEPOINT>
342*8c35d5eeSXin Li
343*8c35d5eeSXin Li    <STYLEPOINT title="Naming">
344*8c35d5eeSXin Li      <SUMMARY>
345*8c35d5eeSXin Li        <p>
346*8c35d5eeSXin Li          In general, use
347*8c35d5eeSXin Li          <code>plugin-names-like-this</code>,
348*8c35d5eeSXin Li          <code>FunctionNamesLikeThis</code>,
349*8c35d5eeSXin Li          <code>CommandNamesLikeThis</code>,
350*8c35d5eeSXin Li          <code>augroup_names_like_this</code>,
351*8c35d5eeSXin Li          <code>variable_names_like_this</code>.
352*8c35d5eeSXin Li        </p>
353*8c35d5eeSXin Li        <p>Always prefix variables with their scope.</p>
354*8c35d5eeSXin Li      </SUMMARY>
355*8c35d5eeSXin Li      <BODY>
356*8c35d5eeSXin Li        <SUBSECTION title="plugin-names-like-this">
357*8c35d5eeSXin Li          <p>Keep them short and sweet.</p>
358*8c35d5eeSXin Li
359*8c35d5eeSXin Li        </SUBSECTION>
360*8c35d5eeSXin Li        <SUBSECTION title="FunctionNamesLikeThis">
361*8c35d5eeSXin Li          <p>Prefix script-local functions with <code>s:</code></p>
362*8c35d5eeSXin Li          <p>Autoloaded functions may not have a scope prefix.</p>
363*8c35d5eeSXin Li          <p>
364*8c35d5eeSXin Li            Do not create global functions. Use autoloaded functions
365*8c35d5eeSXin Li            instead.
366*8c35d5eeSXin Li          </p>
367*8c35d5eeSXin Li        </SUBSECTION>
368*8c35d5eeSXin Li        <SUBSECTION title="CommandNamesLikeThis">
369*8c35d5eeSXin Li          <p>Prefer succinct command names over common command prefixes.</p>
370*8c35d5eeSXin Li        </SUBSECTION>
371*8c35d5eeSXin Li        <SUBSECTION title="variable_names_like_this">
372*8c35d5eeSXin Li          <p>Augroup names count as variables for naming purposes.</p>
373*8c35d5eeSXin Li        </SUBSECTION>
374*8c35d5eeSXin Li        <SUBSECTION title="Prefix all variables with their scope.">
375*8c35d5eeSXin Li          <ul>
376*8c35d5eeSXin Li            <li>Global variables with <code>g:</code></li>
377*8c35d5eeSXin Li            <li>Script-local variables with <code>s:</code></li>
378*8c35d5eeSXin Li            <li>Function arguments with <code>a:</code></li>
379*8c35d5eeSXin Li            <li>Function-local variables with <code>l:</code></li>
380*8c35d5eeSXin Li            <li>Vim-predefined variables with <code>v:</code></li>
381*8c35d5eeSXin Li            <li>Buffer-local variables with <code>b:</code></li>
382*8c35d5eeSXin Li          </ul>
383*8c35d5eeSXin Li          <p>
384*8c35d5eeSXin Li            <code>g:</code>, <code>s:</code>, and <code>a:</code> must always
385*8c35d5eeSXin Li            be used.
386*8c35d5eeSXin Li          </p>
387*8c35d5eeSXin Li          <p>
388*8c35d5eeSXin Li            <code>b:</code> changes the variable semantics; use it when you
389*8c35d5eeSXin Li            want buffer-local semantics.
390*8c35d5eeSXin Li          </p>
391*8c35d5eeSXin Li          <p>
392*8c35d5eeSXin Li            <code>l:</code> and <code>v:</code> should be used for consistency,
393*8c35d5eeSXin Li            future proofing, and to avoid subtle bugs. They are not strictly
394*8c35d5eeSXin Li            required. Add them in new code but don’t go out of your way to add
395*8c35d5eeSXin Li            them elsewhere.
396*8c35d5eeSXin Li          </p>
397*8c35d5eeSXin Li        </SUBSECTION>
398*8c35d5eeSXin Li      </BODY>
399*8c35d5eeSXin Li    </STYLEPOINT>
400*8c35d5eeSXin Li  </CATEGORY>
401*8c35d5eeSXin Li
402*8c35d5eeSXin Li  <p align="right">
403*8c35d5eeSXin Li    Revision 1.1
404*8c35d5eeSXin Li  </p>
405*8c35d5eeSXin Li
406*8c35d5eeSXin Li
407*8c35d5eeSXin Li  <address>
408*8c35d5eeSXin Li    Nate Soares<br/>
409*8c35d5eeSXin Li    Joshua Hoak<br/>
410*8c35d5eeSXin Li    David Barnett<br/>
411*8c35d5eeSXin Li  </address>
412*8c35d5eeSXin Li</GUIDE>
413