C程序員-從校園到職場


第一章 概述

1.1工欲善其事,必先利其器

1.2常用工具軟件

  • SourceInsight
  • Notepad++
  • Araxis Merge/Beyond Compare
  • FTP工具:如FileZilla

1.2.1 Araxis Merge

Araxis Merge是一個可視化的文件比較、合並和同步的軟件,能夠方便地被軟件工程師用於快速精確地比較不同版本的源文件。此外,它還能被用於進行版本和質量控制。

1.2.2 Beyond Compare

Beyond compare是一套由Scooter Software推出的軟件,主要用於文件之間的比較。

第二章 學校到職場

第三章 程序的樣式

3.1 頭文件

/********************************************************
* 版權所有 (C)2015 公司或個人名稱。
* * 文件名稱:
* 內容摘要:
* 其他說明:
* 當前版本:
* 作    者:
* 完成日期:
* * 修改記錄:
* 修改日期:
* 版 本 號:
* 修 改 人:
* 修改內容:
** *****************************************************/

#ifndef _XXX_H //防止頭文件被重復引用
#define _XXX_H

/********************************************************
 相關宏定義
********************************************************/

/*******************************************************
 相關結構體定義
*******************************************************/

/*******************************************************
 源程序中出現的函數聲明
*******************************************************/

#endif

3.2 源文件

/********************************************************
* 版權所有 (C)2015 公司或個人名稱。
* * 文件名稱:
* 內容摘要:
* 其他說明:
* 當前版本:
* 作    者:
* 完成日期:
* * 修改記錄:
* 修改日期:
* 版 本 號:
* 修 改 人:
* 修改內容:
** *****************************************************/

#ifndef _XXX_H //防止頭文件被重復引用
#define _XXX_H

/********************************************************
 頭文件引用
********************************************************/

/*******************************************************
 全局變量定義
*******************************************************/

/*******************************************************
 函數實現
*******************************************************/

#endif

說明:
- 當源程序中的函數比較多時,會出現很多函數都需要使用同一個變量的情況,這就需要定義一個全局變量供他們使用。但全局變量的個數要盡量少,盡量不要定義多余的全局變量,這樣可以減少不同函數之間的耦合性。就拿人類來說,我們依靠別人越少,我們越自由,如果很多事情都要先問問別人的意見,你的心里感覺如何?
- 函數頭部的注釋

/*******************************************************
* 功能描述:
* 輸入參數:
* 輸出參數:
* 返 回 值:
* 其他說明:
* 修改日期      版本號      修改人      修改內容
* YYYYMMDD       XXX         Name         YYY
********************************************************/

3.3 空格和空行

3.3.1 空格

  • c語言的關鍵字之后要留空格,以突出該關鍵字;函數名之后不要留空格,緊跟左括號(,以與關鍵字作區別;但在函數定義的參數之間,要留有空格,如Function(x, y, z)
  • 二元操作符的前后應該加空格,一元操作符的前后不加空格
  • 在一行代碼的結尾之后不要加空格
  • 在代碼中,使用空格進行縮進,一般縮進4個空格,不要使用制表符進行縮進

3.3.2 空行

  • 空行起着分隔程序段落的作用,適當的空行將使程序的布局更加清晰
  • 在每個函數定義結束之后都要加空行,建議加2個以上的空行
  • 函數體內不要隨意加空行,空行多用於分隔關系不是很大的代碼段

3.3.3 大括號

一個函數的所有語句是包括在{}之中的,除此之外,大括號還有其他用處
- 分隔功能關聯不大的語句塊

void function A() {
    //功能A代碼塊開始
    {
        //功能A的實現代碼
    }

    //功能B代碼塊開始
    {
        //功能B實現代碼
    }
}
  • 突出添加或修改的代碼-閱讀和維護代碼容易
void function A()
{
    ......
    ......
    ......

    //修改或添加代碼塊開始
    {
        //修改或添加的代碼
    }
    ......
    ......
    ......
}

3.3.4 注釋

  • //用來單行注釋,/*/用來多行注釋
  • 注釋的位置要與被描述的代碼相鄰,可以放在代碼的上方或者右方,但不可放在下方
  • 注釋應簡單、准確、易懂,防止二義性,避免使用縮寫
  • 邊寫代碼別注釋,修改代碼修改注釋,保持代碼與注釋的一致性
  • 遵循內容重於形式的原則

第四章 變量和函數

4.1 數據類型

在實際工作中,我們需要對一些基本數據類型進行重定義(規范化),才能夠滿足編程規范的要求,才能夠用於定義變量。

4.1.1 整型

typedef unsigned short int UINT16;
typedef signed short int INT16;
typedef unsigned int UINT32;
typedef signed int INT32;
typedef unsigned long ULONG;
typedef signed long LONG;
typedef unsigned char UINT8;
typedef signed char INT8;
  • 在代碼文件中,按照這個規范編寫的程序閱讀起來比較方便,便於理解
  • 提高了工作效率,讓讀者一看就覺着十分專業
  • 這樣做會簡介提升開發工程師在客戶心中的地位,能夠獲得他們比較好的評價。

4.2 變量及函數

  • 變量及函數要有描述性,不要過度縮寫
  • 遵循一個原則讓讀者一眼就能看出他們表達的意思
  • 函數的功能要單一,不要設計多用途的函數;函數體的規模要小,將函數內的代碼行數控制在項目規定的范圍之內。
  • 避免函數帶有記憶功能,相同的輸入應該產生相同的輸出
  • 函數調用的時候,傳入的實參類型要和形參的類型完全一樣。如果不一樣,用代碼檢查工具是很容易發現的。如果確實需要傳入該參數,可使用強制數據類型轉換。
  • 對於有返回值得函數,盡量在被調用的時候對返回值進行處理。不處理的話是不符合規范的。

4.3 靜態變量

在實際的軟件開發中,有一類變量非常特殊-靜態變量。它主要應用於函數中,具有記憶性,即本次函數本次調用時使用的變量值是上一次函數執行結束時該變量的值。

第五章 內存操作

常用內存操作函數-可以參見K&R的書籍《the c program language》

第六章 文件

常用文件操作函數-可以參見K&R的書籍《the c program language》

第七章 指針和結構體

第八章 算法和協議

8.1 算法

  • 圖形化表示——流程圖

8.2 協議

在通信協議中,一條完整的消息由消息頭和消息體組成。在C語言中,用結構體來表示協議,在消息解析的時候,一般只關注消息體的內容。
示例:

//消息頭結構
typedef struct
{
    UINT16 iReserve1;
    UINT16 iReserve2;
    UINT16 iReserve3;
    UINT16 iReserve4;
}MsgHead_T;

//消息結構體(包含消息頭和消息體)
typedef struct
{
    MsgHead_T tMsgHead;//消息頭
    UINT32 iOperType;//操作類型
    UINT8 szUserNumber[30];//用戶號碼
    UINT8 szOperTime[20];//操作時間:yyyymmdd
    UINT32 iReservel;//保留字段1,便於擴展
    UINT8 szReservel[50];//保留字段2
}UserReqMsg_T;

第九章 程序重構

9.1 重構原因

  • 原程序編碼不規范,函數封裝做的不好
  • 源程序架構不能滿足新需求
  • 源程序有bug
  • 源程序效率低下,性能不足以滿足客戶要求

9.2 重構原則

  • 小步快跑:一次一小步的修改模式
  • 兩頂帽子:一頂是只重構源代碼而不增加新功能;一頂是增加新功能以實現新需求
  • 糟糕設計零容忍度:先重構代碼或系統使之適應新需求,在順理成章的去實現這些新需求

第十章 SQL語句和Shell命令

由於自己還沒接觸到這方面的知識,所以就不在這里做記錄了。

第十一章 程序問題排查

根據故障的嚴重程度,軟件故障可以分為3類:
- 嚴重故障

這類故障一般會導致軟件產品無法正常使用,需要立即解決。
- 一般故障

這類故障雖然不會導致軟件產品無法正常使用,但會影響某些功能流程,會影響到用戶的體驗。如果出現了此問題,那么軟件工程師在手中任務不緊張的情況下,需要抽時間來處理掉,不能讓問題一直遺留下去。
- 輕微故障

這類故障幾乎不會對軟件產品產生不良影響,用戶也很少能夠感覺到故障的存在。對於追求高質量和良好用戶口碑的公司,在后續產品功能升級的時候,會附帶將該類問題一起處理掉。

程序問題排查

11.1 日志

11.1.1 日志等級

  • 嚴重錯誤-level1
  • 一般錯誤-level2
  • 警告信息-level3
  • 一般信息-level4
  • 跟蹤信息-level5
  • 調試信息-level6

11.1.2 日志配置

在配置文件中,有一個專門的[LOGINFO]配置段,其中的配置項如下:

[LOGINFO]
;日志等級,1-嚴重錯誤,2-一般錯誤,3-警告信息,4-一般信息,5-跟蹤信息,6-調試信息
LevelOfLog =
;每個日志文件的最大容量
MaxSizeOfLog = 
;是否輸出該條日志在代碼中的位置(行數),1-是,0-否
PositionOfLog = 

11.1.3 日志函數

有兩類寫日志的函數
- 形如WriteLog(LevelOfLog,InfoOfLog)

如:

WriteLog(LOGINFO,“the value of this integer is 3”);
  • 刑如WriteLogEx(LevelOfLog,InfoLog,InfoOfParam),這是擴展的日志函數,不但能夠輸出日志信息,還能夠在日志信息中顯示變量的值

如:

WriteLog(LOGINFO,“the value of this integer is %d”,iInt);

11.1.4 日志說明

日志編寫的總體原則是簡單清晰,便於排查問題。

  1. 分多條信息分別輸出,不要企圖將所有信息一次打印出來
  2. 分時輸出
  3. 必須分日志級別
  4. 控制日志信息的條數,不重要的信息盡量不要打印日志
  5. 所有的輸入輸出,包括收消息和發消息都要求輸出日志
  6. 關鍵控制點必須輸出日志
  7. 調用底層或第三方軟件,必須輸出日志,並且對不可靠底層,必須加上begin/end兩行日志
  8. 對方系統處理事件必須輸出日志,以利以后維護時快速定位性能問題

11.2 配置項問題

  1. 千里之堤,毀於蟻穴,很多軟件問題並不是由很大的缺陷引起的,反而是一些很細小的問題造成的。
  2. 在提交軟件版本之前,對於需要使用配置文件的軟件,相關開發人員一定要認真編寫配置文件使用說明書。在說明書中,要詳細描述每個配置項的配置規則及注意事項,讓即使是不懂程序的人也能夠在很短的時間內看明白並做到正確配置。
  3. 在設置配置值之前,我們一定要對程序的處理流程了然於心,很多軟件本身並沒有問題,但就是因為某些配置項不符合程序要求而導致了整個軟件的故障。
  4. 在運行軟件之前,相關人員要仔細檢查 配置文件中的各個配置項的值,確保每個配置值都是准確無誤的。
  5. 細節決定成敗,只有不斷的實踐,不斷的總結,我們才能夠提高代碼的質量,讓細節問題無處藏身。

11.3 時序問題

  1. 詳盡的日記處理有助於問題的定位
  2. 在消息處理順序很重要的程序中,一定要理清程序執行的前后關系,防止流程越位的情況發生
  3. 在排查問題的過程中,不要放過任何一個蛛絲馬跡,要及時驗證自己的想法,多對程序進行驗證。

11.4 變量初始化問題

11.5 數據表索引問題

總結:

本書可以閑來無事看看,對於還未進入社會的同學來說會提供很多經驗性的參考。但不建議購買。


注意!

本站转载的文章为个人学习借鉴使用,本站对版权不负任何法律责任。如果侵犯了您的隐私权益,请联系我们删除。



 
粤ICP备14056181号  © 2014-2020 ITdaan.com