程序设计实践笔记 - Jiajun的编程随想

首页

/

友情链接

/

我的Github

/

关于我


程序设计实践笔记

Style

Names ~~~~~

.. code:: c

int i = 0;
for (; i < 10; i++)
    ;

Expressions and Statements ~~~~~~~~~~~~~~~~~~~~~~~~~~

.. code:: c

// do not use expressions like
// if (!(block_id < actblks) |!(block_id >= unblocks))
// but in this way:
if ((block_id >= actblks) |(block_id < unblocks))

.. code:: c

// instead of writing expressions like
// leap_year = y % 4 == 0 && y % 100 != 0 |y % 400 == 0;
// write:
leap_year = ((y % 4 == 0) && (y % 100 != 0) |(y % 400 == 0));

.. code:: c

array[i++] = array[i++] = ' ';

Consistency and Idioms ~~~~~~~~~~~~~~~~~~~~~~

.. code:: c

// instead of wrting :
// int i = 0;
// for (i = 0; i < n; )
//     array[i++] = 1;
int i = 0;
for (i = 0; i < n; i++)
    array[i] = 1;

.. code:: c

// write
while (1):
    //
// instead of writing for (;;)

.. code:: vim

set cc=79

.. code:: c

switch (c) {
    case 'a': blablabla; break;
    case 'b': blablabla; break;
    ...
}

but, an acceptable use of fall-through occurs when serveral cases have identical(相同的) code, the conventional layout is like this:

.. code:: c

switch (c) {
    case '0':
    case '1':
    case '2':
        blablabla
        break;
}

Function Macros ~~~~~~~~~~~~~~~

.. code:: c

1/square(x) // works well if square is a function, but not macro:
// #define square(x) (x)*(x), it will be evaluated to:
1/(x) * (x)
// this version works well:
// #define square(x) ((x) * (x))

Magic Numbers ~~~~~~~~~~~~~

.. code:: c

// instead of using:
if (c >= 65 && c <= 90)
// using:
if (c >= 'A' && c <= 'Z')
// this way is the best(use the standard library):
if (isupper(c))

.. code:: c

#define NELEMS(array) (sizeof(array) / sizeof(array[0]))

Comments ~~~~~~~~

Algorithms and Data Structures

Chapter2

-  if you are developing programs in a field that's new to you, you must find out
   what is already known, lest you waste your time doing poorly what others have
   already done well.

-  if repeated searches are going to be made in some data set, it will be
   profitable to sort once and then use binary search.

-  `big-o notation cheat sheet <http://bigocheatsheet.com/>`__

-  这一章主要介绍了常用的数据结构和主要操作,例如List, Tree, Hash
   Table.---

Chapter3

Debugging

Easy bugs

-  look for familiar patterns. ask yourself, "have I seen this before"
   when you get a bug.

-  examine the most recent change. source code control systems and
   other history mechanisms are helpful here. e.g. git.

-  don't make the same mistake twice. easy code can have bugs if its
   familiarity causes us to let down out guard. even when code is so
   simple you could write it in your sleep, don't fall asleep while writing it.

-  debug it now, not later. don't ignore a crash when it happens; track it
  down right away, since it may not happen again until it's too late.o

-  get a stack trace. the source line number of the failure, often
   part a stack trace, is the most useful single piece of debugging infomation;
   improbable(难以置信的,不会的) values of arguments are also a big
   clue(zero pointers, integers that are huge when they should be small,
   or negative when they should be positive, character strings
   that aren't alphabetic).

-  read before typing. one effective but under-appreciated debugging
   technique is to read the code very carefully and think about it
   for a while without making changes. resist the urge to
   start typing, thinking is a worthwhile alternative.

-  explain your code to someone else.
   `小黄鸭调试法?哈哈哈哈 <https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CB4QFjAAahUKEwjK8PS09LTIAhWM5oAKHWwpACU&url=https%3A%2F%2Fzh.wikipedia.org%2Fzh%2F%25E5%25B0%258F%25E9%25BB%2584%25E9%25B8%25AD%25E8%25B0%2583%25E8%25AF%2595%25E6%25B3%2595&usg=AFQjCNHJAF8oTPEFyICQ_QJ9tz_gwKlcvw&sig2=REOYXrZfbO6yu1AsA7QNLQ>`__

Hard bugs

.. code:: c

#ifdef DEBUG
......
#endif

and here is a trick for assert:

.. code:: c

assert(a &gt; b), "a should bigger than b";

so the string after assert(a > b) will be displayed if assert works.

Last Resorts ~~~~~~~~~~~~

what do you do if none of this advice helps? this may be the time to use a good debubger to step through the program. it's tough to find this kind of bug, because your brain takes you right around the mistake, to follow what the program is doing, not what you think it is doing.

if you can't find a bug after considerable work, take a break, clear your mind, do something else, talk to a friend and ask for help.

Other People's Bugs ~~~~~~~~~~~~~~~~~~~

if you think that you have found a bug in someone else's program, the first step is to make absolutely sure it is a genuine bug, so you don't waste the author's time and lose your own credibility.