[19010] | 1 | /* $Id: VBox-CodingGuidelines.cpp 76553 2019-01-01 01:45:53Z vboxsync $ */
|
---|
[6303] | 2 | /** @file
|
---|
| 3 | * VBox - Coding Guidelines.
|
---|
| 4 | */
|
---|
| 5 |
|
---|
| 6 | /*
|
---|
[76553] | 7 | * Copyright (C) 2006-2019 Oracle Corporation
|
---|
[6303] | 8 | *
|
---|
[8155] | 9 | * This file is part of VirtualBox Open Source Edition (OSE), as
|
---|
| 10 | * available from http://www.virtualbox.org. This file is free software;
|
---|
| 11 | * you can redistribute it and/or modify it under the terms of the GNU
|
---|
| 12 | * General Public License (GPL) as published by the Free Software
|
---|
| 13 | * Foundation, in version 2 as it comes in the "COPYING" file of the
|
---|
| 14 | * VirtualBox OSE distribution. VirtualBox OSE is distributed in the
|
---|
| 15 | * hope that it will be useful, but WITHOUT ANY WARRANTY of any kind.
|
---|
[6303] | 16 | */
|
---|
| 17 |
|
---|
| 18 | /** @page pg_vbox_guideline VBox Coding Guidelines
|
---|
| 19 | *
|
---|
[72791] | 20 | * The compulsory sections of these guidelines are to be followed in all of the
|
---|
| 21 | * VBox sources. Please note that local guidelines in parts of the VBox source
|
---|
| 22 | * tree may promote the optional ones to compulsory status. The VBox tree also
|
---|
| 23 | * contains some 3rd party sources where it is good to follow the local coding
|
---|
| 24 | * style while keeping these guidelines in mind.
|
---|
[6303] | 25 | *
|
---|
[72791] | 26 | * Contents:
|
---|
| 27 | * - @ref sec_vbox_guideline_compulsory
|
---|
| 28 | * - @ref sec_vbox_guideline_compulsory_sub64
|
---|
| 29 | * - @ref sec_vbox_guideline_compulsory_cppmain
|
---|
| 30 | * - @ref sec_vbox_guideline_compulsory_cppqtgui
|
---|
| 31 | * - @ref sec_vbox_guideline_compulsory_xslt
|
---|
| 32 | * - @ref sec_vbox_guideline_compulsory_doxygen
|
---|
| 33 | * - @ref sec_vbox_guideline_compulsory_guest
|
---|
| 34 | * - @ref sec_vbox_guideline_optional
|
---|
| 35 | * - @ref sec_vbox_guideline_optional_layout
|
---|
| 36 | * - @ref sec_vbox_guideline_optional_prefix
|
---|
| 37 | * - @ref sec_vbox_guideline_optional_misc
|
---|
| 38 | * - @ref sec_vbox_guideline_warnings
|
---|
| 39 | * - @ref sec_vbox_guideline_warnings_signed_unsigned_compare
|
---|
| 40 | * - @ref sec_vbox_guideline_svn
|
---|
[6303] | 41 | *
|
---|
[72791] | 42 | * Local guidelines overrides:
|
---|
| 43 | * - src/VBox/VMM/: @ref pg_vmm_guideline (src/VBox/VMM/Docs-CodingGuidelines.cpp)
|
---|
| 44 | * - src/VBox/ValidationKit/: @ref pg_validationkit_guideline (src/VBox/ValidationKit/ValidationKitCodingGuidelines.cpp)
|
---|
| 45 | * - src/VBox/Runtime/: All of @ref sec_vbox_guideline_optional is mandatory.
|
---|
| 46 | * - src/VBox/Main/: @ref sec_vbox_guideline_compulsory_cppmain
|
---|
| 47 | * - src/VBox/Frontends/VirtualBox/: @ref sec_vbox_guideline_compulsory_cppqtgui
|
---|
[6303] | 48 | *
|
---|
| 49 | *
|
---|
| 50 | * @section sec_vbox_guideline_compulsory Compulsory
|
---|
| 51 | *
|
---|
[68445] | 52 | * <ul>
|
---|
[6303] | 53 | *
|
---|
[68445] | 54 | * <li> The indentation size is 4 chars.
|
---|
[30954] | 55 | *
|
---|
[68445] | 56 | * <li> Tabs are only ever used in makefiles.
|
---|
[30954] | 57 | *
|
---|
[68445] | 58 | * <li> Use RT and VBOX types.
|
---|
[6303] | 59 | *
|
---|
[68445] | 60 | * <li> Use Runtime functions.
|
---|
[6303] | 61 | *
|
---|
[68445] | 62 | * <li> Use the standard bool, uintptr_t, intptr_t and [u]int[1-9+]_t types.
|
---|
[6303] | 63 | *
|
---|
[68445] | 64 | * <li> Avoid using plain unsigned and int.
|
---|
[6303] | 65 | *
|
---|
[68445] | 66 | * <li> Use static wherever possible. This makes the namespace less polluted
|
---|
[16197] | 67 | * and avoids nasty name clash problems which can occur, especially on
|
---|
[62912] | 68 | * Unix-like systems. (1) It also simplifies locating callers when
|
---|
| 69 | * changing it (single source file vs entire VBox tree).
|
---|
[6303] | 70 | *
|
---|
[68445] | 71 | * <li> Public names are of the form Domain[Subdomain[]]Method, using mixed
|
---|
[6303] | 72 | * casing to mark the words. The main domain is all uppercase.
|
---|
| 73 | * (Think like java, mapping domain and subdomain to packages/classes.)
|
---|
| 74 | *
|
---|
[68445] | 75 | * <li> Public names are always declared using the appropriate DECL macro. (2)
|
---|
[6303] | 76 | *
|
---|
[68445] | 77 | * <li> Internal names starts with a lowercased main domain.
|
---|
[6303] | 78 | *
|
---|
[68445] | 79 | * <li> Defines are all uppercase and separate words with underscore.
|
---|
[6303] | 80 | * This applies to enum values too.
|
---|
| 81 | *
|
---|
[68445] | 82 | * <li> Typedefs are all uppercase and contain no underscores to distinguish
|
---|
[6303] | 83 | * them from defines.
|
---|
| 84 | *
|
---|
[68445] | 85 | * <li> Pointer typedefs start with 'P'. If pointer to const then 'PC'.
|
---|
[6303] | 86 | *
|
---|
[68445] | 87 | * <li> Function typedefs start with 'FN'. If pointer to FN then 'PFN'.
|
---|
[6303] | 88 | *
|
---|
[68445] | 89 | * <li> All files are case sensitive.
|
---|
[6303] | 90 | *
|
---|
[68445] | 91 | * <li> Slashes are unix slashes ('/') runtime converts when necessary.
|
---|
[6303] | 92 | *
|
---|
[68445] | 93 | * <li> char strings are UTF-8.
|
---|
[6303] | 94 | *
|
---|
[68445] | 95 | * <li> Strings from any external source must be treated with utmost care as
|
---|
[57833] | 96 | * they do not have to be valid UTF-8. Only trust internal strings.
|
---|
| 97 | *
|
---|
[68445] | 98 | * <li> All functions return VBox status codes. There are three general
|
---|
[16169] | 99 | * exceptions from this:
|
---|
[68445] | 100 | *
|
---|
| 101 | * <ol>
|
---|
| 102 | * <li>Predicate functions. These are function which are boolean in
|
---|
[16169] | 103 | * nature and usage. They return bool. The function name will
|
---|
| 104 | * include 'Has', 'Is' or similar.
|
---|
[68445] | 105 | * <li>Functions which by nature cannot possibly fail.
|
---|
[6303] | 106 | * These return void.
|
---|
[68445] | 107 | * <li>"Get"-functions which return what they ask for.
|
---|
[6303] | 108 | * A get function becomes a "Query" function if there is any
|
---|
| 109 | * doubt about getting what is ask for.
|
---|
[68445] | 110 | * </ol>
|
---|
[6303] | 111 | *
|
---|
[68445] | 112 | * <li> VBox status codes have three subdivisions:
|
---|
| 113 | * <ol>
|
---|
| 114 | * <li> Errors, which are VERR_ prefixed and negative.
|
---|
| 115 | * <li> Warnings, which are VWRN_ prefixed and positive.
|
---|
| 116 | * <li> Informational, which are VINF_ prefixed and positive.
|
---|
| 117 | * </ol>
|
---|
[6303] | 118 | *
|
---|
[68445] | 119 | * <li> Platform/OS operation are generalized and put in the IPRT.
|
---|
[6303] | 120 | *
|
---|
[68445] | 121 | * <li> Other useful constructs are also put in the IPRT.
|
---|
[6303] | 122 | *
|
---|
[68445] | 123 | * <li> The code shall not cause compiler warnings. Check this on ALL
|
---|
[6303] | 124 | * the platforms.
|
---|
| 125 | *
|
---|
[68445] | 126 | * <li> The use of symbols leading with single or double underscores is
|
---|
[57833] | 127 | * forbidden as that intrudes on reserved compiler/system namespace. (3)
|
---|
| 128 | *
|
---|
[68445] | 129 | * <li> All files have file headers with $Id and a file tag which describes
|
---|
[6303] | 130 | * the file in a sentence or two.
|
---|
[57833] | 131 | * Note: Use the svn-ps.cmd/svn-ps.sh utility with the -a option to add
|
---|
| 132 | * new sources with keyword expansion and exporting correctly
|
---|
| 133 | * configured.
|
---|
[6303] | 134 | *
|
---|
[68445] | 135 | * <li> All public functions are fully documented in Doxygen style using the
|
---|
[16169] | 136 | * javadoc dialect (using the 'at' instead of the 'slash' as
|
---|
| 137 | * commandprefix.)
|
---|
[6303] | 138 | *
|
---|
[68445] | 139 | * <li> All structures in header files are described, including all their
|
---|
[57833] | 140 | * members. (Doxygen style, of course.)
|
---|
[6303] | 141 | *
|
---|
[68445] | 142 | * <li> All modules have a documentation '\@page' in the main source file
|
---|
[57833] | 143 | * which describes the intent and actual implementation.
|
---|
[6303] | 144 | *
|
---|
[68445] | 145 | * <li> Code which is doing things that are not immediately comprehensible
|
---|
[16169] | 146 | * shall include explanatory comments.
|
---|
[6303] | 147 | *
|
---|
[68445] | 148 | * <li> Documentation and comments are kept up to date.
|
---|
[6303] | 149 | *
|
---|
[68445] | 150 | * <li> Headers in /include/VBox shall not contain any slash-slash C++
|
---|
[16169] | 151 | * comments, only ANSI C comments!
|
---|
[6303] | 152 | *
|
---|
[68445] | 153 | * <li> Comments on \#else indicates what begins while the comment on a
|
---|
[57833] | 154 | * \#endif indicates what ended. Only add these when there are more than
|
---|
| 155 | * a few lines (6-10) of \#ifdef'ed code, otherwise they're just clutter.
|
---|
[71660] | 156 | *
|
---|
[71705] | 157 | * <li> \#ifdefs around a single function shall be tight, i.e. no empty
|
---|
| 158 | * lines between it and the function documentation and body.
|
---|
| 159 | *
|
---|
| 160 | * <li> \#ifdefs around more than one function shall be relaxed, i.e. leave at
|
---|
| 161 | * least one line before the first function's documentation comment and
|
---|
| 162 | * one line after the end of the last function.
|
---|
| 163 | *
|
---|
[71660] | 164 | * <li> No 'else' after if block ending with 'return', 'break', or 'continue'.
|
---|
| 165 | *
|
---|
[71739] | 166 | * <li> The term 'last' is inclusive, whereas the term 'end' is exclusive.
|
---|
| 167 | *
|
---|
[71702] | 168 | * <li> Go through all of this: https://www.slideshare.net/olvemaudal/deep-c/
|
---|
| 169 | *
|
---|
[68445] | 170 | * </ul>
|
---|
[6303] | 171 | *
|
---|
| 172 | * (1) It is common practice on Unix to have a single symbol namespace for an
|
---|
| 173 | * entire process. If one is careless symbols might be resolved in a
|
---|
| 174 | * different way that one expects, leading to weird problems.
|
---|
| 175 | *
|
---|
| 176 | * (2) This is common practice among most projects dealing with modules in
|
---|
| 177 | * shared libraries. The Windows / PE __declspect(import) and
|
---|
| 178 | * __declspect(export) constructs are the main reason for this.
|
---|
[16169] | 179 | * OTOH, we do perhaps have a bit too detailed graining of this in VMM...
|
---|
[6303] | 180 | *
|
---|
[57833] | 181 | * (3) There are guys out there grepping public sources for symbols leading with
|
---|
| 182 | * single and double underscores as well as gotos and other things
|
---|
| 183 | * considered bad practice. They'll post statistics on how bad our sources
|
---|
| 184 | * are on some mailing list, forum or similar.
|
---|
[6303] | 185 | *
|
---|
[57833] | 186 | *
|
---|
[6303] | 187 | * @subsection sec_vbox_guideline_compulsory_sub64 64-bit and 32-bit
|
---|
| 188 | *
|
---|
| 189 | * Here are some amendments which address 64-bit vs. 32-bit portability issues.
|
---|
| 190 | *
|
---|
| 191 | * Some facts first:
|
---|
| 192 | *
|
---|
[68445] | 193 | * <ul>
|
---|
| 194 | *
|
---|
| 195 | * <li> On 64-bit Windows the type long remains 32-bit. On nearly all other
|
---|
[6303] | 196 | * 64-bit platforms long is 64-bit.
|
---|
| 197 | *
|
---|
[68445] | 198 | * <li> On all 64-bit platforms we care about, int is 32-bit, short is 16 bit
|
---|
[6303] | 199 | * and char is 8-bit.
|
---|
| 200 | * (I don't know about any platforms yet where this isn't true.)
|
---|
| 201 | *
|
---|
[68445] | 202 | * <li> size_t, ssize_t, uintptr_t, ptrdiff_t and similar are all 64-bit on
|
---|
[6303] | 203 | * 64-bit platforms. (These are 32-bit on 32-bit platforms.)
|
---|
| 204 | *
|
---|
[68445] | 205 | * <li> There is no inline assembly support in the 64-bit Microsoft compilers.
|
---|
[6303] | 206 | *
|
---|
[68445] | 207 | * </ul>
|
---|
[6303] | 208 | *
|
---|
| 209 | * Now for the guidelines:
|
---|
| 210 | *
|
---|
[68445] | 211 | * <ul>
|
---|
| 212 | *
|
---|
| 213 | * <li> Never, ever, use int, long, ULONG, LONG, DWORD or similar to cast a
|
---|
[63292] | 214 | * pointer to integer. Use uintptr_t or intptr_t. If you have to use
|
---|
[6303] | 215 | * NT/Windows types, there is the choice of ULONG_PTR and DWORD_PTR.
|
---|
| 216 | *
|
---|
[68445] | 217 | * <li> Avoid where ever possible the use of the types 'long' and 'unsigned
|
---|
[63292] | 218 | * long' as these differs in size between windows and the other hosts
|
---|
| 219 | * (see above).
|
---|
| 220 | *
|
---|
[68445] | 221 | * <li> RT_OS_WINDOWS is defined to indicate Windows. Do not use __WIN32__,
|
---|
[16169] | 222 | * __WIN64__ and __WIN__ because they are all deprecated and scheduled
|
---|
[6303] | 223 | * for removal (if not removed already). Do not use the compiler
|
---|
| 224 | * defined _WIN32, _WIN64, or similar either. The bitness can be
|
---|
| 225 | * determined by testing ARCH_BITS.
|
---|
| 226 | * Example:
|
---|
| 227 | * @code
|
---|
| 228 | * #ifdef RT_OS_WINDOWS
|
---|
| 229 | * // call win32/64 api.
|
---|
| 230 | * #endif
|
---|
| 231 | * #ifdef RT_OS_WINDOWS
|
---|
| 232 | * # if ARCH_BITS == 64
|
---|
| 233 | * // call win64 api.
|
---|
| 234 | * # else // ARCH_BITS == 32
|
---|
| 235 | * // call win32 api.
|
---|
| 236 | * # endif // ARCH_BITS == 32
|
---|
| 237 | * #else // !RT_OS_WINDOWS
|
---|
| 238 | * // call posix api
|
---|
| 239 | * #endif // !RT_OS_WINDOWS
|
---|
| 240 | * @endcode
|
---|
| 241 | *
|
---|
[68445] | 242 | * <li> There are RT_OS_xxx defines for each OS, just like RT_OS_WINDOWS
|
---|
[6303] | 243 | * mentioned above. Use these defines instead of any predefined
|
---|
| 244 | * compiler stuff or defines from system headers.
|
---|
| 245 | *
|
---|
[68445] | 246 | * <li> RT_ARCH_X86 is defined when compiling for the x86 the architecture.
|
---|
[6303] | 247 | * Do not use __x86__, __X86__, __[Ii]386__, __[Ii]586__, or similar
|
---|
| 248 | * for this purpose.
|
---|
| 249 | *
|
---|
[68445] | 250 | * <li> RT_ARCH_AMD64 is defined when compiling for the AMD64 architecture.
|
---|
[6303] | 251 | * Do not use __AMD64__, __amd64__ or __x64_86__.
|
---|
| 252 | *
|
---|
[68445] | 253 | * <li> Take care and use size_t when you have to, esp. when passing a pointer
|
---|
[6303] | 254 | * to a size_t as a parameter.
|
---|
| 255 | *
|
---|
[68445] | 256 | * <li> Be wary of type promotion to (signed) integer. For example the
|
---|
[9396] | 257 | * following will cause u8 to be promoted to int in the shift, and then
|
---|
| 258 | * sign extended in the assignment 64-bit:
|
---|
| 259 | * @code
|
---|
| 260 | * uint8_t u8 = 0xfe;
|
---|
| 261 | * uint64_t u64 = u8 << 24;
|
---|
| 262 | * // u64 == 0xfffffffffe000000
|
---|
| 263 | * @endcode
|
---|
[6303] | 264 | *
|
---|
[68445] | 265 | * </ul>
|
---|
[6303] | 266 | *
|
---|
[21440] | 267 | * @subsection sec_vbox_guideline_compulsory_cppmain C++ guidelines for Main
|
---|
| 268 | *
|
---|
[73806] | 269 | * Since the Main API code is a large amount of C++ code, it is allowed but
|
---|
| 270 | * not required to use C++ style comments (as permanent comments, beyond the
|
---|
| 271 | * temporary use allowed by the general coding guideline). This is a weak
|
---|
| 272 | * preference, i.e. large scale comment style changes are not encouraged.
|
---|
| 273 | *
|
---|
[21440] | 274 | * Main is currently (2009) full of hard-to-maintain code that uses complicated
|
---|
| 275 | * templates. The new mid-term goal for Main is to have less custom templates
|
---|
| 276 | * instead of more for the following reasons:
|
---|
| 277 | *
|
---|
[68445] | 278 | * <ul>
|
---|
[21440] | 279 | *
|
---|
[68445] | 280 | * <li> Template code is harder to read and understand. Custom templates create
|
---|
| 281 | * territories which only the code writer understands.
|
---|
[21440] | 282 | *
|
---|
[68445] | 283 | * <li> Errors in using templates create terrible C++ compiler messages.
|
---|
[21440] | 284 | *
|
---|
[68445] | 285 | * <li> Template code is really hard to look at in a debugger.
|
---|
[21440] | 286 | *
|
---|
[68445] | 287 | * <li> Templates slow down the compiler a lot.
|
---|
[21440] | 288 | *
|
---|
[68445] | 289 | * </ul>
|
---|
[21440] | 290 | *
|
---|
[68445] | 291 | * In particular, the following bits should be considered deprecated and should
|
---|
| 292 | * NOT be used in new code:
|
---|
[21440] | 293 | *
|
---|
[68445] | 294 | * <ul>
|
---|
[21440] | 295 | *
|
---|
[68445] | 296 | * <li> everything in include/iprt/cpputils.h (auto_ref_ptr, exception_trap_base,
|
---|
| 297 | * char_auto_ptr and friends)
|
---|
[21440] | 298 | *
|
---|
[68445] | 299 | * </ul>
|
---|
| 300 | *
|
---|
| 301 | * Generally, in many cases, a simple class with a proper destructor can achieve
|
---|
| 302 | * the same effect as a 1,000-line template include file, and the code is
|
---|
| 303 | * much more accessible that way.
|
---|
| 304 | *
|
---|
| 305 | * Using standard STL templates like std::list, std::vector and std::map is OK.
|
---|
| 306 | * Exceptions are:
|
---|
| 307 | *
|
---|
| 308 | * <ul>
|
---|
| 309 | *
|
---|
| 310 | * <li> Guest Additions because we don't want to link against libstdc++ there.
|
---|
| 311 | *
|
---|
| 312 | * <li> std::string should not be used because we have iprt::MiniString and
|
---|
[21440] | 313 | * com::Utf8Str which can convert efficiently with COM's UTF-16 strings.
|
---|
| 314 | *
|
---|
[68445] | 315 | * <li> std::auto_ptr<> in general; that part of the C++ standard is just broken.
|
---|
[21440] | 316 | * Write a destructor that calls delete.
|
---|
| 317 | *
|
---|
[68445] | 318 | * </ul>
|
---|
[21440] | 319 | *
|
---|
[26352] | 320 | * @subsection sec_vbox_guideline_compulsory_cppqtgui C++ guidelines for the Qt GUI
|
---|
[21449] | 321 | *
|
---|
[26352] | 322 | * The Qt GUI is currently (2010) on its way to become more compatible to the
|
---|
| 323 | * rest of VirtualBox coding style wise. From now on, all the coding style
|
---|
| 324 | * rules described in this file are also mandatory for the Qt GUI. Additionally
|
---|
| 325 | * the following rules should be respected:
|
---|
| 326 | *
|
---|
[68445] | 327 | * <ul>
|
---|
[26352] | 328 | *
|
---|
[68445] | 329 | * <li> GUI classes which correspond to GUI tasks should be prefixed by UI (no VBox anymore)
|
---|
[26352] | 330 | *
|
---|
[68445] | 331 | * <li> Classes which extents some of the Qt classes should be prefix by QI
|
---|
[26352] | 332 | *
|
---|
[68445] | 333 | * <li> General task classes should be prefixed by C
|
---|
[26352] | 334 | *
|
---|
[68445] | 335 | * <li> Slots are prefixed by slt -> sltName
|
---|
[26352] | 336 | *
|
---|
[68445] | 337 | * <li> Signals are prefixed by sig -> sigName
|
---|
| 338 | *
|
---|
| 339 | * <li> Use Qt classes for lists, strings and so on, the use of STL classes should
|
---|
[26352] | 340 | * be avoided
|
---|
| 341 | *
|
---|
[68445] | 342 | * <li> All files like .cpp, .h, .ui, which belong together are located in the
|
---|
[26352] | 343 | * same directory and named the same
|
---|
| 344 | *
|
---|
[68445] | 345 | * </ul>
|
---|
[26352] | 346 | *
|
---|
[68445] | 347 | *
|
---|
[53944] | 348 | * @subsection sec_vbox_guideline_compulsory_xslt XSLT
|
---|
| 349 | *
|
---|
| 350 | * XSLT (eXtensible Stylesheet Language Transformations) is used quite a bit in
|
---|
| 351 | * the Main API area of VirtualBox to generate sources and bindings to that API.
|
---|
| 352 | * There are a couple of common pitfalls worth mentioning:
|
---|
| 353 | *
|
---|
[68445] | 354 | * <ul>
|
---|
| 355 | *
|
---|
| 356 | * <li> Never do repeated //interface[\@name=...] and //enum[\@name=...] lookups
|
---|
[53944] | 357 | * because they are expensive. Instead delcare xsl:key elements for these
|
---|
| 358 | * searches and do the lookup using the key() function. xsltproc uses
|
---|
| 359 | * (per current document) hash tables for each xsl:key, i.e. very fast.
|
---|
| 360 | *
|
---|
[68445] | 361 | * <li> When output type is 'text' make sure to call xsltprocNewlineOutputHack
|
---|
[53944] | 362 | * from typemap-shared.inc.xsl every few KB of output, or xsltproc will
|
---|
| 363 | * end up wasting all the time reallocating the output buffer.
|
---|
| 364 | *
|
---|
[68445] | 365 | * </ul>
|
---|
[53944] | 366 | *
|
---|
[71660] | 367 | *
|
---|
[57833] | 368 | * @subsection sec_vbox_guideline_compulsory_doxygen Doxygen Comments
|
---|
| 369 | *
|
---|
| 370 | * As mentioned above, we shall use doxygen/javadoc style commenting of public
|
---|
[71660] | 371 | * functions, typedefs, classes and such. It is mandatory to use this style
|
---|
| 372 | * everywhere!
|
---|
[57833] | 373 | *
|
---|
| 374 | * A couple of hints on how to best write doxygen comments:
|
---|
| 375 | *
|
---|
[68445] | 376 | * <ul>
|
---|
| 377 | *
|
---|
| 378 | * <li> A good class, method, function, structure or enum doxygen comment
|
---|
[57833] | 379 | * starts with a one line sentence giving a brief description of the
|
---|
| 380 | * item. Details comes in a new paragraph (after blank line).
|
---|
| 381 | *
|
---|
[68445] | 382 | * <li> Except for list generators like \@todo, \@cfgm, \@gcfgm and others,
|
---|
[57833] | 383 | * all doxygen comments are related to things in the code. So, for
|
---|
| 384 | * instance you DO NOT add a doxygen \@note comment in the middle of a
|
---|
| 385 | * because you've got something important to note, you add a normal
|
---|
| 386 | * comment like 'Note! blah, very importan blah!'
|
---|
| 387 | *
|
---|
[68445] | 388 | * <li> We do NOT use TODO/XXX/BUGBUG or similar markers in the code to flag
|
---|
[57833] | 389 | * things needing fixing later, we always use \@todo doxygen comments.
|
---|
| 390 | *
|
---|
[68445] | 391 | * <li> There is no colon after the \@todo. And it is ALWAYS in a doxygen
|
---|
[57833] | 392 | * comment.
|
---|
| 393 | *
|
---|
[68445] | 394 | * <li> The \@retval tag is used to explain status codes a method/function may
|
---|
[57833] | 395 | * returns. It is not used to describe output parameters, that is done
|
---|
| 396 | * using the \@param or \@param[out] tag.
|
---|
| 397 | *
|
---|
[68445] | 398 | * </ul>
|
---|
| 399 | *
|
---|
[57833] | 400 | * See https://www.stack.nl/~dimitri/doxygen/manual/index.html for the official
|
---|
| 401 | * doxygen documention.
|
---|
| 402 | *
|
---|
| 403 | *
|
---|
[71660] | 404 | *
|
---|
| 405 | * @subsection sec_vbox_guideline_compulsory_guest Handling of guest input
|
---|
| 406 | *
|
---|
| 407 | * First, guest input should ALWAYS be consider to be TOXIC and constructed with
|
---|
| 408 | * MALICIOUS intent! Max paranoia level!
|
---|
| 409 | *
|
---|
| 410 | * Second, when getting inputs from memory shared with the guest, be EXTREMELY
|
---|
| 411 | * careful to not re-read input from shared memory after validating it, because
|
---|
| 412 | * that will create TOCTOU problems. So, after reading input from shared memory
|
---|
[71685] | 413 | * always use the RT_UNTRUSTED_NONVOLATILE_COPY_FENCE() macro. For more details
|
---|
[71660] | 414 | * on TOCTOU: https://en.wikipedia.org/wiki/Time_of_check_to_time_of_use
|
---|
| 415 | *
|
---|
| 416 | * Thirdly, considering the recent speculation side channel issues, spectre v1
|
---|
| 417 | * in particular, we would like to be ready for future screwups. This means
|
---|
| 418 | * having input validation in a separate block of code that ends with one (or
|
---|
| 419 | * more) RT_UNTRUSTED_VALIDATED_FENCE().
|
---|
| 420 | *
|
---|
| 421 | * So the rules:
|
---|
| 422 | *
|
---|
| 423 | * <ul>
|
---|
| 424 | *
|
---|
| 425 | * <li> Mark all pointers to shared memory with RT_UNTRUSTED_VOLATILE_GUEST.
|
---|
| 426 | *
|
---|
| 427 | * <li> Copy volatile data into local variables or heap before validating
|
---|
| 428 | * them (see RT_COPY_VOLATILE() and RT_BCOPY_VOLATILE().
|
---|
| 429 | *
|
---|
| 430 | * <li> Place RT_UNTRUSTED_NONVOLATILE_COPY_FENCE() after a block copying
|
---|
| 431 | * volatile data.
|
---|
| 432 | *
|
---|
| 433 | * <li> Always validate untrusted inputs in a block ending with a
|
---|
| 434 | * RT_UNTRUSTED_VALIDATED_FENCE().
|
---|
| 435 | *
|
---|
| 436 | * <li> Use the ASSERT_GUEST_XXXX macros from VBox/AssertGuest.h to validate
|
---|
| 437 | * guest input. (Do NOT use iprt/assert.h macros.)
|
---|
| 438 | *
|
---|
| 439 | * <li> Validation of an input B may require using another input A to look up
|
---|
| 440 | * some data, in which case its necessary to insert an
|
---|
| 441 | * RT_UNTRUSTED_VALIDATED_FENCE() after validating A and before A is used
|
---|
| 442 | * for the lookup.
|
---|
| 443 | *
|
---|
| 444 | * For example A is a view identifier, idView, and B is an offset into
|
---|
| 445 | * the view's framebuffer area, offView. To validate offView (B) it is
|
---|
| 446 | * necessary to get the size of the views framebuffer region:
|
---|
| 447 | * @code
|
---|
| 448 | * uint32_t const idView = pReq->idView; // A
|
---|
| 449 | * uint32_t const offView = pReq->offView; // B
|
---|
| 450 | * RT_UNTRUSTED_NONVOLATILE_COPY_FENCE();
|
---|
| 451 | *
|
---|
| 452 | * ASSERT_GUEST_RETURN(idView < pThis->cView,
|
---|
| 453 | * VERR_INVALID_PARAMETER);
|
---|
| 454 | * RT_UNTRUSTED_VALIDATED_FENCE();
|
---|
| 455 | * const MYVIEW *pView = &pThis->aViews[idView];
|
---|
| 456 | * ASSERT_GUEST_RETURN(offView < pView->cbFramebufferArea,
|
---|
| 457 | * VERR_OUT_OF_RANGE);
|
---|
| 458 | * RT_UNTRUSTED_VALIDATED_FENCE();
|
---|
| 459 | * @endcode
|
---|
| 460 | *
|
---|
| 461 | * <li> Take care to make sure input check are not subject to integer overflow problems.
|
---|
| 462 | *
|
---|
| 463 | * For instance when validating an area, you must not just add cbDst + offDst
|
---|
| 464 | * and check against pThis->offEnd or something like that. Rather do:
|
---|
| 465 | * @code
|
---|
| 466 | * uint32_t const offDst = pReq->offDst;
|
---|
| 467 | * uint32_t const cbDst = pReq->cbDst;
|
---|
| 468 | * RT_UNTRUSTED_NONVOLATILE_COPY_FENCE();
|
---|
| 469 | *
|
---|
| 470 | * ASSERT_GUEST_RETURN( cbDst <= pThis->cbSrc
|
---|
| 471 | * && offDst < pThis->cbSrc - cbDst,
|
---|
| 472 | * VERR_OUT_OF_RANGE);
|
---|
| 473 | * RT_UNTRUSTED_VALIDATED_FENCE();
|
---|
| 474 | * @endcode
|
---|
| 475 | *
|
---|
| 476 | * <li> Input validation does not only apply to shared data cases, but also to
|
---|
| 477 | * I/O port and MMIO handlers.
|
---|
| 478 | *
|
---|
| 479 | * <li> Ditto for kernel drivers working with usermode inputs.
|
---|
| 480 | *
|
---|
| 481 | * </ul>
|
---|
| 482 | *
|
---|
| 483 | *
|
---|
| 484 | * Problem patterns:
|
---|
| 485 | * - https://en.wikipedia.org/wiki/Time_of_check_to_time_of_use
|
---|
| 486 | * - https://googleprojectzero.blogspot.de/2018/01/reading-privileged-memory-with-side.html
|
---|
| 487 | * (Variant 1 only).
|
---|
| 488 | * - https://en.wikipedia.org/wiki/Integer_overflow
|
---|
| 489 | *
|
---|
| 490 | *
|
---|
| 491 | *
|
---|
[6303] | 492 | * @section sec_vbox_guideline_optional Optional
|
---|
| 493 | *
|
---|
[30954] | 494 | * First part is the actual coding style and all the prefixes. The second part
|
---|
[16169] | 495 | * is a bunch of good advice.
|
---|
[6303] | 496 | *
|
---|
| 497 | *
|
---|
| 498 | * @subsection sec_vbox_guideline_optional_layout The code layout
|
---|
| 499 | *
|
---|
[68445] | 500 | * <ul>
|
---|
| 501 | *
|
---|
| 502 | * <li> Max line length is 130 chars. Exceptions are table-like
|
---|
[30954] | 503 | * code/initializers and Log*() statements (don't waste unnecessary
|
---|
| 504 | * vertical space on debug logging).
|
---|
[6303] | 505 | *
|
---|
[68445] | 506 | * <li> Comments should try stay within the usual 80 columns as these are
|
---|
[44115] | 507 | * denser and too long lines may be harder to read.
|
---|
[6303] | 508 | *
|
---|
[68445] | 509 | * <li> Curly brackets are not indented. Example:
|
---|
[6303] | 510 | * @code
|
---|
[30954] | 511 | * if (true)
|
---|
| 512 | * {
|
---|
| 513 | * Something1();
|
---|
| 514 | * Something2();
|
---|
| 515 | * }
|
---|
| 516 | * else
|
---|
| 517 | * {
|
---|
| 518 | * SomethingElse1().
|
---|
| 519 | * SomethingElse2().
|
---|
| 520 | * }
|
---|
| 521 | * @endcode
|
---|
| 522 | *
|
---|
[68445] | 523 | * <li> Space before the parentheses when it comes after a C keyword.
|
---|
[30954] | 524 | *
|
---|
[68445] | 525 | * <li> No space between argument and parentheses. Exception for complex
|
---|
[30954] | 526 | * expression. Example:
|
---|
| 527 | * @code
|
---|
[6303] | 528 | * if (PATMR3IsPatchGCAddr(pVM, GCPtr))
|
---|
| 529 | * @endcode
|
---|
| 530 | *
|
---|
[68445] | 531 | * <li> The else of an if is always the first statement on a line. (No curly
|
---|
[6303] | 532 | * stuff before it!)
|
---|
| 533 | *
|
---|
[68445] | 534 | * <li> else and if go on the same line if no { compound statement }
|
---|
[30954] | 535 | * follows the if. Example:
|
---|
[6303] | 536 | * @code
|
---|
| 537 | * if (fFlags & MYFLAGS_1)
|
---|
| 538 | * fFlags &= ~MYFLAGS_10;
|
---|
| 539 | * else if (fFlags & MYFLAGS_2)
|
---|
| 540 | * {
|
---|
| 541 | * fFlags &= ~MYFLAGS_MASK;
|
---|
| 542 | * fFlags |= MYFLAGS_5;
|
---|
| 543 | * }
|
---|
| 544 | * else if (fFlags & MYFLAGS_3)
|
---|
| 545 | * @endcode
|
---|
| 546 | *
|
---|
[68445] | 547 | * <li> Slightly complex boolean expressions are split into multiple lines,
|
---|
[30954] | 548 | * putting the operators first on the line and indenting it all according
|
---|
| 549 | * to the nesting of the expression. The purpose is to make it as easy as
|
---|
| 550 | * possible to read. Example:
|
---|
| 551 | * @code
|
---|
| 552 | * if ( RT_SUCCESS(rc)
|
---|
| 553 | * || (fFlags & SOME_FLAG))
|
---|
| 554 | * @endcode
|
---|
| 555 | *
|
---|
[68445] | 556 | * <li> When 'if' or 'while' statements gets long, the closing parentheses
|
---|
[30954] | 557 | * goes right below the opening parentheses. This may be applied to
|
---|
| 558 | * sub-expression. Example:
|
---|
| 559 | * @code
|
---|
| 560 | * if ( RT_SUCCESS(rc)
|
---|
| 561 | * || ( fSomeStuff
|
---|
| 562 | * && fSomeOtherStuff
|
---|
| 563 | * && fEvenMoreStuff
|
---|
| 564 | * )
|
---|
| 565 | * || SomePredicateFunction()
|
---|
| 566 | * )
|
---|
| 567 | * {
|
---|
| 568 | * ...
|
---|
| 569 | * }
|
---|
| 570 | * @endcode
|
---|
| 571 | *
|
---|
[68445] | 572 | * <li> The case is indented from the switch (to avoid having the braces for
|
---|
[30954] | 573 | * the 'case' at the same level as the 'switch' statement).
|
---|
| 574 | *
|
---|
[68445] | 575 | * <li> If a case needs curly brackets they contain the entire case, are not
|
---|
[6303] | 576 | * indented from the case, and the break or return is placed inside them.
|
---|
| 577 | * Example:
|
---|
| 578 | * @code
|
---|
| 579 | * switch (pCur->eType)
|
---|
| 580 | * {
|
---|
| 581 | * case PGMMAPPINGTYPE_PAGETABLES:
|
---|
| 582 | * {
|
---|
| 583 | * unsigned iPDE = pCur->GCPtr >> PGDIR_SHIFT;
|
---|
| 584 | * unsigned iPT = (pCur->GCPtrEnd - pCur->GCPtr) >> PGDIR_SHIFT;
|
---|
| 585 | * while (iPT-- > 0)
|
---|
| 586 | * if (pPD->a[iPDE + iPT].n.u1Present)
|
---|
| 587 | * return VERR_HYPERVISOR_CONFLICT;
|
---|
| 588 | * break;
|
---|
| 589 | * }
|
---|
| 590 | * }
|
---|
| 591 | * @endcode
|
---|
| 592 | *
|
---|
[68445] | 593 | * <li> In a do while construction, the while is on the same line as the
|
---|
[16169] | 594 | * closing "}" if any are used.
|
---|
[6303] | 595 | * Example:
|
---|
| 596 | * @code
|
---|
| 597 | * do
|
---|
| 598 | * {
|
---|
| 599 | * stuff;
|
---|
| 600 | * i--;
|
---|
| 601 | * } while (i > 0);
|
---|
| 602 | * @endcode
|
---|
| 603 | *
|
---|
[68445] | 604 | * <li> Comments are in C style. C++ style comments are used for temporary
|
---|
[6303] | 605 | * disabling a few lines of code.
|
---|
| 606 | *
|
---|
[68445] | 607 | * <li> No unnecessary parentheses in expressions (just don't over do this
|
---|
[6303] | 608 | * so that gcc / msc starts bitching). Find a correct C/C++ operator
|
---|
| 609 | * precedence table if needed.
|
---|
| 610 | *
|
---|
[68445] | 611 | * <li> 'for (;;)' is preferred over 'while (true)' and 'while (1)'.
|
---|
[6303] | 612 | *
|
---|
[68445] | 613 | * <li> Parameters are indented to the start parentheses when breaking up
|
---|
[30954] | 614 | * function calls, declarations or prototypes. (This is in line with
|
---|
| 615 | * how 'if', 'for' and 'while' statements are done as well.) Example:
|
---|
| 616 | * @code
|
---|
| 617 | * RTPROCESS hProcess;
|
---|
| 618 | * int rc = RTProcCreateEx(papszArgs[0],
|
---|
| 619 | * papszArgs,
|
---|
| 620 | * RTENV_DEFAULT,
|
---|
| 621 | * fFlags,
|
---|
| 622 | * NULL, // phStdIn
|
---|
| 623 | * NULL, // phStdOut
|
---|
| 624 | * NULL, // phStdErr
|
---|
| 625 | * NULL, // pszAsUser
|
---|
| 626 | * NULL, // pszPassword
|
---|
| 627 | * &hProcess);
|
---|
| 628 | * @endcode
|
---|
| 629 | *
|
---|
[68445] | 630 | * <li> That Dijkstra is dead is no excuse for using gotos.
|
---|
[30954] | 631 | *
|
---|
[68445] | 632 | * <li> Using do-while-false loops to avoid gotos is considered very bad form.
|
---|
[62704] | 633 | * They create hard to read code. They tend to be either too short (i.e.
|
---|
| 634 | * pointless) or way to long (split up the function already), making
|
---|
| 635 | * tracking the state is difficult and prone to bugs. Also, they cause
|
---|
| 636 | * the compiler to generate suboptimal code, because the break branches
|
---|
| 637 | * are by preferred over the main code flow (MSC has no branch hinting!).
|
---|
| 638 | * Instead, do make use the 130 columns (i.e. nested ifs) and split
|
---|
| 639 | * the code up into more functions!
|
---|
[30954] | 640 | *
|
---|
[68445] | 641 | * <li> Avoid code like
|
---|
| 642 | * @code
|
---|
| 643 | * int foo;
|
---|
| 644 | * int rc;
|
---|
| 645 | * ...
|
---|
| 646 | * rc = FooBar();
|
---|
| 647 | * if (RT_SUCCESS(rc))
|
---|
| 648 | * {
|
---|
| 649 | * foo = getFoo();
|
---|
| 650 | * ...
|
---|
| 651 | * pvBar = RTMemAlloc(sizeof(*pvBar));
|
---|
| 652 | * if (!pvBar)
|
---|
| 653 | * rc = VERR_NO_MEMORY;
|
---|
[69209] | 654 | * }
|
---|
[68445] | 655 | * if (RT_SUCCESS(rc))
|
---|
| 656 | * {
|
---|
| 657 | * buzz = foo;
|
---|
| 658 | * ...
|
---|
| 659 | * }
|
---|
| 660 | * @endcode
|
---|
| 661 | * The intention of such code is probably to save some horizontal space
|
---|
| 662 | * but unfortunately it's hard to read and the scope of certain varables
|
---|
| 663 | * (e.g. foo in this example) is not optimal. Better use the following
|
---|
| 664 | * style:
|
---|
| 665 | * @code
|
---|
| 666 | * int rc;
|
---|
| 667 | * ...
|
---|
| 668 | * rc = FooBar();
|
---|
| 669 | * if (RT_SUCCESS(rc))
|
---|
| 670 | * {
|
---|
| 671 | * int foo = getFoo();
|
---|
| 672 | * ...
|
---|
| 673 | * pvBar = RTMemAlloc(sizeof(*pvBar));
|
---|
| 674 | * if (pvBar)
|
---|
| 675 | * {
|
---|
| 676 | * buzz = foo;
|
---|
| 677 | * ...
|
---|
| 678 | * }
|
---|
| 679 | * else
|
---|
| 680 | * rc = VERR_NO_MEMORY;
|
---|
| 681 | * }
|
---|
| 682 | * @endcode
|
---|
[30954] | 683 | *
|
---|
[68445] | 684 | * </ul>
|
---|
| 685 | *
|
---|
[6303] | 686 | * @subsection sec_vbox_guideline_optional_prefix Variable / Member Prefixes
|
---|
| 687 | *
|
---|
[44115] | 688 | * Prefixes are meant to provide extra context clues to a variable/member, we
|
---|
| 689 | * therefore avoid using prefixes that just indicating the type if a better
|
---|
| 690 | * choice is available.
|
---|
| 691 | *
|
---|
| 692 | *
|
---|
| 693 | * The prefixes:
|
---|
| 694 | *
|
---|
[68445] | 695 | * <ul>
|
---|
[6303] | 696 | *
|
---|
[68445] | 697 | * <li> The 'g_' (or 'g') prefix means a global variable, either on file or module level.
|
---|
| 698 | *
|
---|
| 699 | * <li> The 's_' (or 's') prefix means a static variable inside a function or
|
---|
[62912] | 700 | * class. This is not used for static variables on file level, use 'g_'
|
---|
| 701 | * for those (logical, right).
|
---|
[6303] | 702 | *
|
---|
[68445] | 703 | * <li> The 'm_' (or 'm') prefix means a class data member.
|
---|
[6303] | 704 | *
|
---|
[30954] | 705 | * In new code in Main, use "m_" (and common sense). As an exception,
|
---|
| 706 | * in Main, if a class encapsulates its member variables in an anonymous
|
---|
[25113] | 707 | * structure which is declared in the class, but defined only in the
|
---|
[30954] | 708 | * implementation (like this: 'class X { struct Data; Data *m; }'), then
|
---|
| 709 | * the pointer to that struct is called 'm' itself and its members then
|
---|
| 710 | * need no prefix, because the members are accessed with 'm->member'
|
---|
| 711 | * already which is clear enough.
|
---|
[25113] | 712 | *
|
---|
[68445] | 713 | * <li> The 'a_' prefix means a parameter (argument) variable. This is
|
---|
[30954] | 714 | * sometimes written 'a' in parts of the source code that does not use
|
---|
| 715 | * the array prefix.
|
---|
[6303] | 716 | *
|
---|
[68445] | 717 | * <li> The 'p' prefix means pointer. For instance 'pVM' is pointer to VM.
|
---|
[6303] | 718 | *
|
---|
[68445] | 719 | * <li> The 'r' prefix means that something is passed by reference.
|
---|
[6303] | 720 | *
|
---|
[68445] | 721 | * <li> The 'k' prefix means that something is a constant. For instance
|
---|
[30954] | 722 | * 'enum { kStuff };'. This is usually not used in combination with
|
---|
| 723 | * 'p', 'r' or any such thing, it's main main use is to make enums
|
---|
| 724 | * easily identifiable.
|
---|
| 725 | *
|
---|
[68445] | 726 | * <li> The 'a' prefix means array. For instance 'aPages' could be read as
|
---|
[30954] | 727 | * array of pages.
|
---|
| 728 | *
|
---|
[68445] | 729 | * <li> The 'c' prefix means count. For instance 'cbBlock' could be read,
|
---|
[62705] | 730 | * count of bytes in block. (1)
|
---|
[30954] | 731 | *
|
---|
[68445] | 732 | * <li> The 'cx' prefix means width (count of 'x' units).
|
---|
[44115] | 733 | *
|
---|
[68445] | 734 | * <li> The 'cy' prefix means height (count of 'y' units).
|
---|
[44115] | 735 | *
|
---|
[68445] | 736 | * <li> The 'x', 'y' and 'z' prefix refers to the x-, y- , and z-axis
|
---|
[44115] | 737 | * respectively.
|
---|
| 738 | *
|
---|
[68445] | 739 | * <li> The 'off' prefix means offset.
|
---|
[6303] | 740 | *
|
---|
[68445] | 741 | * <li> The 'i' or 'idx' prefixes usually means index. Although the 'i' one
|
---|
[30954] | 742 | * can sometimes just mean signed integer.
|
---|
[6303] | 743 | *
|
---|
[68445] | 744 | * <li> The 'i[1-9]+' prefix means a fixed bit size variable. Frequently
|
---|
[44115] | 745 | * used with the int[1-9]+_t types where the width is really important.
|
---|
| 746 | * In most cases 'i' is more appropriate. [type]
|
---|
[30954] | 747 | *
|
---|
[68445] | 748 | * <li> The 'e' (or 'enm') prefix means enum.
|
---|
[6303] | 749 | *
|
---|
[68445] | 750 | * <li> The 'u' prefix usually means unsigned integer. Exceptions follows.
|
---|
[6303] | 751 | *
|
---|
[68445] | 752 | * <li> The 'u[1-9]+' prefix means a fixed bit size variable. Frequently
|
---|
[44115] | 753 | * used with the uint[1-9]+_t types and with bitfields where the width is
|
---|
| 754 | * really important. In most cases 'u' or 'b' (byte) would be more
|
---|
| 755 | * appropriate. [type]
|
---|
[6303] | 756 | *
|
---|
[68445] | 757 | * <li> The 'b' prefix means byte or bytes. [type]
|
---|
[6303] | 758 | *
|
---|
[68445] | 759 | * <li> The 'f' prefix means flags. Flags are unsigned integers of some kind
|
---|
[30954] | 760 | * or booleans.
|
---|
[6303] | 761 | *
|
---|
[68445] | 762 | * <li> TODO: need prefix for real float. [type]
|
---|
[6303] | 763 | *
|
---|
[68445] | 764 | * <li> The 'rd' prefix means real double and is used for 'double' variables.
|
---|
[30954] | 765 | * [type]
|
---|
[6303] | 766 | *
|
---|
[68445] | 767 | * <li> The 'lrd' prefix means long real double and is used for 'long double'
|
---|
[30954] | 768 | * variables. [type]
|
---|
[6303] | 769 | *
|
---|
[68445] | 770 | * <li> The 'ch' prefix means a char, the (signed) char type. [type]
|
---|
[6303] | 771 | *
|
---|
[68445] | 772 | * <li> The 'wc' prefix means a wide/windows char, the RTUTF16 type. [type]
|
---|
[6303] | 773 | *
|
---|
[68445] | 774 | * <li> The 'uc' prefix means a Unicode Code point, the RTUNICP type. [type]
|
---|
[6303] | 775 | *
|
---|
[68445] | 776 | * <li> The 'uch' prefix means unsigned char. It's rarely used. [type]
|
---|
[6303] | 777 | *
|
---|
[68445] | 778 | * <li> The 'sz' prefix means zero terminated character string (array of
|
---|
[30954] | 779 | * chars). (UTF-8)
|
---|
| 780 | *
|
---|
[68445] | 781 | * <li> The 'wsz' prefix means zero terminated wide/windows character string
|
---|
[30954] | 782 | * (array of RTUTF16).
|
---|
| 783 | *
|
---|
[68445] | 784 | * <li> The 'usz' prefix means zero terminated Unicode string (array of
|
---|
[30954] | 785 | * RTUNICP).
|
---|
| 786 | *
|
---|
[68445] | 787 | * <li> The 'str' prefix means C++ string; either a std::string or, in Main,
|
---|
[30954] | 788 | * a Utf8Str or, in Qt, a QString. When used with 'p', 'r', 'a' or 'c'
|
---|
| 789 | * the first letter should be capitalized.
|
---|
[25113] | 790 | *
|
---|
[68445] | 791 | * <li> The 'bstr' prefix, in Main, means a UTF-16 Bstr. When used with 'p',
|
---|
[30954] | 792 | * 'r', 'a' or 'c' the first letter should be capitalized.
|
---|
[25113] | 793 | *
|
---|
[68445] | 794 | * <li> The 'pfn' prefix means pointer to function. Common usage is 'pfnCallback'
|
---|
[6303] | 795 | * and such like.
|
---|
| 796 | *
|
---|
[68445] | 797 | * <li> The 'psz' prefix is a combination of 'p' and 'sz' and thus means
|
---|
[30954] | 798 | * pointer to a zero terminated character string. (UTF-8)
|
---|
[6303] | 799 | *
|
---|
[68445] | 800 | * <li> The 'pcsz' prefix is used to indicate constant string pointers in
|
---|
[30954] | 801 | * parts of the code. Most code uses 'psz' for const and non-const
|
---|
[62705] | 802 | * string pointers, so please ignore this one.
|
---|
[30954] | 803 | *
|
---|
[68445] | 804 | * <li> The 'l' prefix means (signed) long. We try avoid using this,
|
---|
[30954] | 805 | * expecially with the 'LONG' types in Main as these are not 'long' on
|
---|
| 806 | * 64-bit non-Windows platforms and can cause confusion. Alternatives:
|
---|
| 807 | * 'i' or 'i32'. [type]
|
---|
| 808 | *
|
---|
[68445] | 809 | * <li> The 'ul' prefix means unsigned long. We try avoid using this,
|
---|
[30954] | 810 | * expecially with the 'ULONG' types in Main as these are not 'unsigned
|
---|
| 811 | * long' on 64-bit non-Windows platforms and can cause confusion.
|
---|
| 812 | * Alternatives: 'u' or 'u32'. [type]
|
---|
| 813 | *
|
---|
[68445] | 814 | * </ul>
|
---|
[30954] | 815 | *
|
---|
[62705] | 816 | * (1) Except in the occasional 'pcsz' prefix, the 'c' prefix is never ever
|
---|
| 817 | * used in the meaning 'const'.
|
---|
| 818 | *
|
---|
| 819 | *
|
---|
[6303] | 820 | * @subsection sec_vbox_guideline_optional_misc Misc / Advice / Stuff
|
---|
| 821 | *
|
---|
[68445] | 822 | * <ul>
|
---|
[6303] | 823 | *
|
---|
[68445] | 824 | * <li> When writing code think as the reader.
|
---|
[6303] | 825 | *
|
---|
[68445] | 826 | * <li> When writing code think as the compiler. (2)
|
---|
[6303] | 827 | *
|
---|
[68445] | 828 | * <li> When reading code think as if it's full of bugs - find them and fix them.
|
---|
| 829 | *
|
---|
| 830 | * <li> Pointer within range tests like:
|
---|
[6303] | 831 | * @code
|
---|
| 832 | * if ((uintptr_t)pv >= (uintptr_t)pvBase && (uintptr_t)pv < (uintptr_t)pvBase + cbRange)
|
---|
| 833 | * @endcode
|
---|
| 834 | * Can also be written as (assuming cbRange unsigned):
|
---|
| 835 | * @code
|
---|
| 836 | * if ((uintptr_t)pv - (uintptr_t)pvBase < cbRange)
|
---|
| 837 | * @endcode
|
---|
| 838 | * Which is shorter and potentially faster. (1)
|
---|
| 839 | *
|
---|
[68445] | 840 | * <li> Avoid unnecessary casting. All pointers automatically cast down to
|
---|
[16169] | 841 | * void *, at least for non class instance pointers.
|
---|
[6303] | 842 | *
|
---|
[68445] | 843 | * <li> It's very very bad practise to write a function larger than a
|
---|
[16169] | 844 | * screen full (1024x768) without any comprehensibility and explaining
|
---|
| 845 | * comments.
|
---|
[6303] | 846 | *
|
---|
[68445] | 847 | * <li> More to come....
|
---|
[6303] | 848 | *
|
---|
[68445] | 849 | * </ul>
|
---|
[6303] | 850 | *
|
---|
| 851 | * (1) Important, be very careful with the casting. In particular, note that
|
---|
| 852 | * a compiler might treat pointers as signed (IIRC).
|
---|
| 853 | *
|
---|
[26668] | 854 | * (2) "A really advanced hacker comes to understand the true inner workings of
|
---|
| 855 | * the machine - he sees through the language he's working in and glimpses
|
---|
| 856 | * the secret functioning of the binary code - becomes a Ba'al Shem of
|
---|
| 857 | * sorts." (Neal Stephenson "Snow Crash")
|
---|
[6303] | 858 | *
|
---|
| 859 | *
|
---|
| 860 | *
|
---|
| 861 | * @section sec_vbox_guideline_warnings Compiler Warnings
|
---|
| 862 | *
|
---|
| 863 | * The code should when possible compile on all platforms and compilers without any
|
---|
| 864 | * warnings. That's a nice idea, however, if it means making the code harder to read,
|
---|
| 865 | * less portable, unreliable or similar, the warning should not be fixed.
|
---|
| 866 | *
|
---|
| 867 | * Some of the warnings can seem kind of innocent at first glance. So, let's take the
|
---|
| 868 | * most common ones and explain them.
|
---|
| 869 | *
|
---|
[21449] | 870 | *
|
---|
[6303] | 871 | * @subsection sec_vbox_guideline_warnings_signed_unsigned_compare Signed / Unsigned Compare
|
---|
| 872 | *
|
---|
| 873 | * GCC says: "warning: comparison between signed and unsigned integer expressions"
|
---|
| 874 | * MSC says: "warning C4018: '<|<=|==|>=|>' : signed/unsigned mismatch"
|
---|
| 875 | *
|
---|
| 876 | * The following example will not output what you expect:
|
---|
| 877 | @code
|
---|
| 878 | #include <stdio.h>
|
---|
| 879 | int main()
|
---|
| 880 | {
|
---|
| 881 | signed long a = -1;
|
---|
| 882 | unsigned long b = 2294967295;
|
---|
| 883 | if (a < b)
|
---|
| 884 | printf("%ld < %lu: true\n", a, b);
|
---|
| 885 | else
|
---|
| 886 | printf("%ld < %lu: false\n", a, b);
|
---|
| 887 | return 0;
|
---|
| 888 | }
|
---|
| 889 | @endcode
|
---|
[16169] | 890 | * If I understood it correctly, the compiler will convert a to an
|
---|
| 891 | * unsigned long before doing the compare.
|
---|
[6303] | 892 | *
|
---|
| 893 | *
|
---|
[21449] | 894 | *
|
---|
[6303] | 895 | * @section sec_vbox_guideline_svn Subversion Commit Rules
|
---|
| 896 | *
|
---|
| 897 | *
|
---|
| 898 | * Before checking in:
|
---|
| 899 | *
|
---|
[68445] | 900 | * <ul>
|
---|
| 901 | *
|
---|
| 902 | * <li> Check Tinderbox and make sure the tree is green across all platforms. If it's
|
---|
[6303] | 903 | * red on a platform, don't check in. If you want, warn in the \#vbox channel and
|
---|
| 904 | * help make the responsible person fix it.
|
---|
| 905 | * NEVER CHECK IN TO A BROKEN BUILD.
|
---|
| 906 | *
|
---|
[68445] | 907 | * <li> When checking in keep in mind that a commit is atomic and that the Tinderbox and
|
---|
[6303] | 908 | * developers are constantly checking out the tree. Therefore do not split up the
|
---|
[16169] | 909 | * commit unless it's into 100% independent parts. If you need to split it up in order
|
---|
[6303] | 910 | * to have sensible commit comments, make the sub-commits as rapid as possible.
|
---|
| 911 | *
|
---|
[68445] | 912 | * <li> If you make a user visible change, such as fixing a reported bug,
|
---|
[16169] | 913 | * make sure you add an entry to doc/manual/user_ChangeLogImpl.xml.
|
---|
[6303] | 914 | *
|
---|
[68445] | 915 | * <li> If you are adding files make sure set the right attributes.
|
---|
[21449] | 916 | * svn-ps.sh/cmd was created for this purpose, please make use of it.
|
---|
[6303] | 917 | *
|
---|
[68445] | 918 | * </ul>
|
---|
[21449] | 919 | *
|
---|
[6303] | 920 | * After checking in:
|
---|
| 921 | *
|
---|
[68445] | 922 | * <ul>
|
---|
| 923 | *
|
---|
| 924 | * <li> After checking-in, you watch Tinderbox until your check-ins clear. You do not
|
---|
[6303] | 925 | * go home. You do not sleep. You do not log out or experiment with drugs. You do
|
---|
| 926 | * not become unavailable. If you break the tree, add a comment saying that you're
|
---|
| 927 | * fixing it. If you can't fix it and need help, ask in the \#innotek channel or back
|
---|
| 928 | * out the change.
|
---|
| 929 | *
|
---|
[68445] | 930 | * </ul>
|
---|
| 931 | *
|
---|
[6303] | 932 | * (Inspired by mozilla tree rules.)
|
---|
[72781] | 933 | *
|
---|
| 934 | *
|
---|
[6303] | 935 | */
|
---|
| 936 |
|
---|