Differences between revisions 7 and 10 (spanning 3 versions)
Revision 7 as of 2006-04-26 09:17:39
Size: 4303
Editor: jnan
Comment:
Revision 10 as of 2006-04-26 12:39:25
Size: 6924
Editor: jnan
Comment:
Deletions are marked like this. Additions are marked like this.
Line 11: Line 11:

= Coding Style =
  * 先看 [http://lxr.linux.no/source/Documentation/CodingStyle Linux kernel coding style]
== Indentation ==
  * 8-char indent
  * If you need more than 3 levels of indentation, you're screwed anyway, and should fix your program.
  * Don't put multiple statements on a single line unless you have something to hide.
  * Get a decent editor, and don't leave whitespace at the end of lines.
== Breaking long lines and strings ==
  * Coding style is all about readability and maintainabilty using commonly avaible tools.
  * The limit on the length of lines is 80 colums and this is a hard limit.
== Placing braces ==
  * The preferred way, as shown to us by the prophets Kernighan and Ritchie, is to put the opening brace last on the line, and put the closing brace first.
  * namely function have the opening brace at the begining of the next line.
== Naming ==
  * C is a Spartan language, and so should your naming be.
  * GLOBAL variables (to be used only if you _really_need them) need to have descriptive name, as do global functions.
  * LOCAL variable name should be short, and to the point.
== Fuctions ==
  * Fuctions should be short and sweet, and do just one thind.
  * Another measure of the functions is the number of local variables, They shouldn't exceed 5-10, or you're doing something wrong.
== Centralized exiting of functions ==
  * About gogo statement.
== Commenting ==
  * Comments are good, but there is also a demage of over-commenting.
  * Generally, you want your comments to tell WHAT your code does, not HOW.
== You've made a mess of it ==
  * About GNU Emacs and GNU indent.
  * 'indent' is not a fix for bad programing.
== Data structures ==
  * Data structures that have visibility outside the single-threaded environment they are created and destoryed in should always have reference counts.
  * Locking is _not_ a replacement for reference counting.
  * If another thread can find your data structure, and you don't have a reference count on it, you almost certainly have a bug.
== Macros, Enums, Inline functions and RTL ==
  * Names of macros defining contants and labels in enums are capitalized.
  * Enums are preferred when defining serval related constants.
  * Generally, inline functions are preferable to macros resembling functions.
  * Macros with multiple statements should be enclosed in a do-while block.
Line 30: Line 68:
  * 可视(visual)模式,用于选定文本块;可以在正常模式下输入“v”(小写)来按字符选定,输入“V”(大写)来按行选定,或输入“Ctrl-V”来按方块选定。

TableOfContents

1. 关于我

个人信息

http://blog.woodpecker.org.cn/planet/images/someone.png

Jick Nan

邮件

[email protected]

主页

http://jick.nan.googlepages.com

Blog

[http://my.donews.com/jnan/ 梦南录]

2. Coding Style

2.1. Indentation

  • 8-char indent
  • If you need more than 3 levels of indentation, you're screwed anyway, and should fix your program.
  • Don't put multiple statements on a single line unless you have something to hide.
  • Get a decent editor, and don't leave whitespace at the end of lines.

2.2. Breaking long lines and strings

  • Coding style is all about readability and maintainabilty using commonly avaible tools.
  • The limit on the length of lines is 80 colums and this is a hard limit.

2.3. Placing braces

  • The preferred way, as shown to us by the prophets Kernighan and Ritchie, is to put the opening brace last on the line, and put the closing brace first.
  • namely function have the opening brace at the begining of the next line.

2.4. Naming

  • C is a Spartan language, and so should your naming be.
  • GLOBAL variables (to be used only if you _really_need them) need to have descriptive name, as do global functions.
  • LOCAL variable name should be short, and to the point.

2.5. Fuctions

  • Fuctions should be short and sweet, and do just one thind.
  • Another measure of the functions is the number of local variables, They shouldn't exceed 5-10, or you're doing something wrong.

2.6. Centralized exiting of functions

  • About gogo statement.

2.7. Commenting

  • Comments are good, but there is also a demage of over-commenting.
  • Generally, you want your comments to tell WHAT your code does, not HOW.

2.8. You've made a mess of it

  • About GNU Emacs and GNU indent.
  • 'indent' is not a fix for bad programing.

2.9. Data structures

  • Data structures that have visibility outside the single-threaded environment they are created and destoryed in should always have reference counts.
  • Locking is _not_ a replacement for reference counting.
  • If another thread can find your data structure, and you don't have a reference count on it, you almost certainly have a bug.

2.10. Macros, Enums, Inline functions and RTL

  • Names of macros defining contants and labels in enums are capitalized.
  • Enums are preferred when defining serval related constants.
  • Generally, inline functions are preferable to macros resembling functions.
  • Macros with multiple statements should be enclosed in a do-while block.

3. C

3.1. malloc, calloc, free

  • 一个严重的错误:释放不是通过调用 malloc, calloc 得到的指针所指向的存储空间。
  • 使用已释放空间同样是错误的。

4. Gnu Tools

4.1. Vim

4.1.1. Edit a file

4.1.1.1. Move around quickly

  • If you set the incsearch option, Vim will show the first match for the pattern, while you are still typing it. This quickly shows a typo in the pattern.

  • If you set hlsearch option, Vim will highlight all matches for the pattern with a yellow background.

  • If you see a specific word and want to search for other occurrences of the same word, use the * command to grab the word from under the cursor and search for the next one, while # search for the previous one.

  • In structured text(C/C++)
    • % can jump to many different matching items. It is very useful to check if() and {} constructs are balanced properly.

    • Use [{ to jump back to the "{" at the start of the current code block, and ]} for '}'.

    • Use gd to jump from the use of variable to its local declaration.

  • 可视(visual)模式,用于选定文本块;可以在正常模式下输入“v”(小写)来按字符选定,输入“V”(大写)来按行选定,或输入“Ctrl-V”来按方块选定。

4.1.1.2. Don't type it twice

  • If you want to change one word into another in the whole file, you can use the :s(substitute) command.

  • If you want to change one word into another only a few locations, a quick method is to use the * command to find the next occurrence of the word and use cw to change the word. Then type n to find the next word and .(dot) to repeat the cw command.

  • CTRL-N can auto complete function and variable names. Vim looks up words in the file you are editing, and also in #include'd files.

  • Vim has a mechanism to record a macro. You type qa to start recording into register 'a'. Then you type your commands as usual and finally hit q again to stop recording. When you want to repeat the recorded commands you type @a.

4.1.1.3. Fix it when it's wrong

  • It's normal to make errors while typing, this can be corrected with abbreviations: :abbr Lunix Linux.

  • The same mechanism can be used to type a long word with just a few characters: :abbr pn pinguin.

  • To find errors in your text Vim has a clever hightlighting mechanism. This was actually meant to be used to do syntax hightlighting of programs, but it can catch and highlight errors as well.
  • A more complex example: English text.

4.1.2. Edit more files

4.1.2.1. A file seldom comes alone

  • Tag mechanism works for jumping between files.
  • Another powerful mechanism is to find all occurrences of a name in a group of files, using the :grep command. Vim makes a list of all matches, and jumps to the first one. The :cn command takes you to each next match.

  • Positions the cursor on the name of the function in your file and type [i: Vim will show a list of all matches for the function name in the included files.

  • In vim you can split the text erea in several parts to edit different files.
  • There are more uses of multiple window. The preview-tag mechanism is a very good example.

4.1.2.2. Let's work together

  • Select some structured text in a list and sort it: !sort.

4.1.2.3. Text is structured

  • One of the simpler things is to speed up the edit-compile-fix cycle. Vim has the :make command, which starts your compilations, catches the errors it produces and lets you jump to the error locations to fix the problems.

4.1.3. Sharpen the saw

4.1.3.1. Make it a habit

  • You need to learn new commands and turn them into a habit.

4.2. CVS

5. 反馈

欢迎大家对我说三道四哪

jick_nan (last edited 2009-12-25 07:12:35 by localhost)