1. 關於c語言的問題
C的函數實際上就是一個代碼功能模塊，完成一定的操作。有些操作並不需要有什麼事先設置的操作對象，如在屏幕上顯示系統的當前時間，就可以寫一個沒有參數的函數把系統時間字元串輸出的屏幕上就可以了——類似這樣的需求是很多的，都可以編制無參函數實現。
2. C/C++程序中的event該如何理解
c c++並沒有event功能。
不過一些事件循環框架 例如windows 的核心庫和qt這類是有event的。 還有很多項目也用到event這個概念，這個玩意就是設計上的一個概念， 一般來說是用來降低耦合的， 比如我寫了一個模塊用來做IO， 成功後會發一個event， coordinator收到這個event會調用其他業務邏輯模塊來做一些操作。 這種設計在C語言項目中比較多， 因為C語言的項目層次結構一般比較散比較平， 不太好做成層次結構， 需要消息隊列這類手段來協調各種功能。
3. 怎樣降低iOS代碼耦合性
凡是維護過中型項目的iOS工程師都應該有過類似的體驗：ViewController代碼繁重、功能復雜、維護困難，整個工程寥寥幾個ViewController就完成了整個項目的開發。每個控制器中都囊括了所有的頁面布局、委託代理、網路請求、資料庫操作和核心功能，這樣的代碼往往問題重重，修改起來牽一發而動全身，著實令人頭疼。
為了應對這一系列的問題，蘋果公司的工程師給我們提供了很多選擇去更好的在項目工程中貫徹MVC的設計理念，例如使用從前的Interface Builder製作xib可視布局，現在已經內置到xcode裡面，並且提供了更為強大Storyboard功能，來減少控制器中的頁面樣式布局代碼量；再例如NSFetchedResultsController這樣的類和的完美結合，大大減少類似構架項目的代碼量，並且穩定高效。
這些技巧在objc.io上有一個專門的專題，推薦給大家對應中文站objc中國，感謝objc 中國項目組。
Storyboard與代碼耦合性
如果放在兩年前去討論iOS工程要不要使用Stortboard進行布局，我們可能還會猶豫一下，很多iOS程序猿內心會有一種想把一切化為代碼掌控在手中的想法，選擇拒絕使用Storyboard或者更早的xib。但事到如今，iPhone、iPad的屏幕尺寸越來越多，工程里為了適配不同屏幕冗餘代碼越來越長的時候，Storyboard似乎成為了我們必須同時也是蘋果公司在引導我們將要實踐的方向。
從iOS 6中的Autolayout到iOS 8中的Size Class，新技術的涌現正是為了應對更復雜的布局任務。有人可能會反駁說，自動布局也可以用純代碼完成呀。你說的沒錯，純代碼是可以完成，但其復雜程度遠遠不是重寫Frame這么簡單了，更靈活地將Storyboard和代碼結合，才是比較完備的解決方案。
這里通過三個方面介紹通過使用Storyboard減小工程代碼耦合性的途徑：
•IBDesignable和IBInspectable
•預覽Storyboard Preview
•NSObject和Runtime Attributes
IBDesignable和IBInspectable
IBDesignable和IBInspectable的出現為Storyboard提供了可視化使用高度自定義控制項的方法，例子中我們在製作一個雙行標簽控制項，用來顯示日期和星期，命名為DateLabel，使用方法如下：
?12345678 //IB_DESIGNABLE 標記 IB_DESIGNABLE @interface DateLabel : UIView //IBInspectable 標記 @property (nonatomic, strong) IBInspectable NSString* dateLabelText; @property (nonatomic, strong) IBInspectable NSString* weekLabelText; @end
其中，IB_DESIGNABLE標記賦予我們的繼承類DateLabel可以在界面編輯器裡面實時渲染的特權。IBInspectable則賦予讓界面編輯器可以設置或者預置View的參數dateLabelText和weekLabelText。具體不多介紹了，有點跑題，大家可以參見如何在iOS 8中使用Swift和Xcode 6製作精美的UI組件，同樣適用於Objective-C和Swift。
引用上文介IBInspectable支持Int,CGFloat,Double,String,Bool,CGPoint,CGSize,
CGRect,UIColor,UIImage等類型的變數。
現在在Github上已經有一部分開源的UI控制項使用了這項特性，如此一來，很多需要在代碼中實現的控制項自定義特性，都可以在Storyboard中完成，後者的優勢也很明顯：
1.所見即所得
2.剝離了ViewController中的定製View代碼，減小耦合
預覽Storyboard Preview
Storybord中提供了預覽功能，可以預覽其界面在各個尺寸設備上的真實顯示效果。詳見Xcode 6中學習Swift、CloudKit 和 Testflight，搜索Storyboard Preview。
NSObject和Runtime Attributes
大家對這個概念再熟悉不過了，但大家有沒有對他作為一個沒有界面的控制項在Storyboard作用產生過疑問呢。先來看下這篇文章 0代碼ViewController的前言。
Storyboard中的NSObject可以是UITableView的DataSource,也可以是MapView的Delegate，連線一下，就能將原本在ViewController中寫得最多的代理方法全部移出，並且，當你需要的時候，這些現成的代理方法，可以直接移到其他的項目中使用。
Runtime Attributes功能則可以在Storyboard中給參數寫好初始值，但這里如果控制項沒有對應的參數的話，則會出現下面的報錯。
Failed to set (xxx) user defined inspected property on (xxx): [ setValue:forUndefinedKey:]: this class is not key value coding-compliant for the key xxx.
Storyboard小結
當你了解了Storyboard的基本原理，就會發現Storyboard是一個很好用的工具，是Model-View-Controller模型中Controller跳轉邏輯和View初始化的實用載體，從根本上把Controller中的導航代碼移出，把頁面配置代碼、觸摸事件甚至協議委託方法分攤到其他實例中，各個類各司其職，整個項目的邏輯也變的更加清晰、更易維護。
4. C語言的設計模式有哪些
最近不少同學都報名參加計算機考試，我們學的是C語言，今天小編就給大家普及一下關於C語言
知識，C語言的設計模式有哪些？
C語言是一門通用計算機編程語言，應用廣泛。C語言的設計目標是提供一種能以簡易的方式編譯、處理低級存儲器、產生少量的機器碼以及不需要任何運行環境支持便能運行的編程語言。C語言是由UNIX的研製者丹尼斯·里奇（Dennis Ritchie）於1970年 由 肯·湯普遜（Ken Thompson）所研製出的B語言的基礎上發展和完善起來的。
說實話學習C語言是非常有難度的，所以說想學C語言的朋友要認真啦。
5. c語言怎麼減少programspace
減少辦法：使用#pragmapack(1)位元組對齊結構；在結構可以包含不同類型的數據的地方使用聯合；使用位欄位而不是整數來存儲標志和小整數；避免使用固定長度的字元數組來存儲字元串，實現字元串池和使用指針。
programspace：程序空間，內存是計算機系統中一個主要部件，用於保存進程運行時的程序和數據，也稱可執行存儲器。在計算機中，內存空間一般是指主存儲器空間（物理地址空間）或系統為一個用戶程序分配內存空間。擴展內存空間的方法一般有增加內存大小和虛擬內存。
空間是與時間相對的一種物質客觀存在形式，但兩者密不可分，按照宇宙大爆炸理論，宇宙從奇點爆炸之後，宇宙的狀態由初始的「一」分裂開來，從而有了不同的存在形式、運動狀態等差異，物與物的位置差異度量稱之為「空間」，位置的變化則由「時間」度量。空間由長度、寬度、高度、大小表現出來。通常指四方（方向）上下。6. c語言程序如何做到高內聚低耦合
要做到高內聚低耦合，重點並不是代碼的編寫，而是整體程序的設計階段。
程序設計時，要先將要實現的功能列出來，然後設計模塊。
模塊設計後，再進行代碼實現。
要做到高內聚低耦合，設計模塊時需要做到：
1 各個模塊之間的功能必須明確；
2 各個功能模塊間實現的功能不可以有交叉；
3 不允許出現模塊間的相互調用；
4 如果必須出現模塊間調用，那麼只允許單向調用，即A可以調用B，B不可以調用A。
只要做到以上效果，就可以實現高內聚低耦合，在代碼實現過程中，可能會額外增加一些代碼的復雜度，但為了降低維護難度，這樣做是很有必要的。7. 有關C語言的問題:什麼是模塊的內聚程度和耦合程度(希望能得到詳解)
對於開發者而言，耦合原則表示程序中單個的模塊應該盡可能的獨立。
處理一個模塊時，不應該依賴另一個模塊的內部工作。
內聚原則是指，在一個給定的模塊內部，所有的代碼應該只完成一個單個的目標。
IT界有一句很著名的口號：強內聚、松耦合。
即使是最初級的程序員，在常常的被教導中，他也了解了這句口號的含義：我們的程序要模塊化，模塊要完成明確的一組關聯的服務功能，要求它的各部分是相關的、有機組合起來是完整體（外部程序來看黑盒子），模塊的內部各成分之間相關聯程度要盡可能高（強內聚）；而模塊與模塊之間又要求是可分拆的、少依賴的（松耦合）。
人們易於實現強內聚的模塊，例如：一個函數實現一個獨立的功能，這就是強內聚。
人們不易實現松耦合，因為，孤獨的模塊毫無意義，只有模塊間的相互協調地工作，才能實現系統的目的。而對於模塊間的相互關系的設計，沒有一定的經驗是難以把握。耦合的強度依賴於：（1）一個模塊對另一個模塊的調用；（2）一個模塊向另一個模塊傳遞的數據量；（3）一個模塊施加到另一個模塊的控制的多少；（4）模塊之間介面的復雜程度。等等。
當然，「強內聚、松耦合」也是有矛盾的，如：內聚性越強，則要求的函數越多（每個函數只作一件「事」），這樣，將它們組合成「大」的功能，也就越復雜，就不可能達到松耦合。因此，應在二者之間作出平衡與折衷的選擇，這也體現程序員的水平。從系統論的角度來看，系統是有層次的，即系統可以分為子系統，模塊可分為子模塊，「強內聚、松耦合」的「度」的把握，應結合系統的次層性來考慮，即通常應在層次性上作出折衷，如：模塊內子程序（下一個層次上）應共享數據（有一定的耦合度），而減少全局變數能降低子程序性間的耦合性。
面向對象的語言進一步強化了「強內聚、松耦合」，類的封裝性既強調了相關內容（數據及其操作）的內聚，又強調了類的獨立性和私密性。而類的繼承性以及友元等，就是在松耦合的原則下規范了類之間的關聯關系。類與類之間通常通過介面的契約實現服務提供者/服務請求者模式，這就是典型的松耦合。
「強內聚、松耦合」對於程序編寫分工、程序的可維護性以及測試都有重要的關系，如：從設計角度來看，在「強內聚、松耦合」的指導下進行的設計得到的程序模塊，符合項目管理的WBS（工作分解結構）的要求，其相對獨立的模塊可以分配到具體的程序員進行開發，另外，程序編碼外包也必須建立在這種原則的設計之下；從程序生命期角度來看，它有利於提高程序質量，特別是方便於程序的日後維護，即程序模塊的相對獨立性是可維護性的保證；再從測試角度來看，符合「強內聚、松耦合」的程序，易於對局部（模塊）進行黑盒測試，也易於編寫測試用的「樁」和「驅動」。
「強內聚、松耦合」也是對組織結構的要求，項目組分為幾個小組（正式的或非正式的），各小組的工作應是高度相關的，各小組之間的工作應盡量是較少相關或有明確的介面，從而減少溝通成本。其實，「強內聚、松耦合」是系統中應遵守的普遍原則，我們在許多領域都可以找到它的應用。
「強內聚、松耦合」是我們不得不念的「三字經」，我們一定要念好它。8. C語言編程可讀性問題:1)通過隱式的條件縮減代碼量以及嵌套次數,還是2)不惜一切代價表現作者意圖代碼為例:
我同意shamork1的看法。他的看法具有指導性。
我附加上一些信息。
1)通過隱式的條件縮減代碼量以及嵌套次數
2)不惜一切代價表現作者意圖
關於你的問題，我有個例子
代碼1：
void processEvent(void)
{
TEvent event;
// catch event;
switch (event)
{
case EVNET_1:
EventHandler1();
break;
case EVENT_2:
EventHandler2();
break;
// so many cases
default:
break;
}
}
代碼2：
void processEvent(void)
{
TEvent event;
TEventHandler* proc;
//catch event;
if (event != EVENT_IDLE)
{
proc=gCurrentNode.EventHandler[event];
proc();
}
}
你覺得哪個可讀性好？我一度認為代碼2是最好的解決方案。
因為代碼2是將switch條件用base+offset的形式轉化了。不僅減少了條件判斷，而且彈性很大（回調函數），在不為數據段添加過多的負載的情況下減少了代碼量,並且重要的是，邏輯上也很清楚。
但是實際情況是，這種代碼2的結構使用起來要比代碼1麻煩的多。
代碼1是我從一個40個分支的代碼中（421行代碼，而且是多重if結構的）抽出來的，我第一眼看到這個結構的時候簡直要瘋了，可是一旦當你熟悉了代碼1的結構以後，你會發現新添一個分支是很容易的事情，只需要在末尾添加代碼即可；修改分支也不會在代碼間跳來跳去。
但是代碼2（另外一個項目中的代碼，具有7個分支），新添事件處理函數卻並不容易，需要往返於頭文件與源文件之間，並且在源文件上還需要多次跳轉，最要命的是調試的時候你不知道將會進入哪個分支，必須添加額外的watch才能明確。
現在再評定一下哪個可讀性好？
再舉個例子，我用到的一個模塊提供了4個介面函數（一對get/set，兩個get）。這四個函數用來訪問總量1萬多個的數據。get/set對攜帶四個函數（其中有結構體），並且這四個函數在不同的情況下具有不同的含義，另外兩個get相對簡單，但每個也需要攜帶三個參數。
從這個例子上看，這四個函數本身的可讀性很好，通過名字就能看出它們的含義，但是如何使用並不是一目瞭然的，以至於我為了使用這四個函數專門編寫了一個文檔來區分何時傳遞什麼樣的變數進去，又會得到什麼樣的輸出。我絲毫不覺得這樣的代碼寫出來可讀性好，因為不論是對於我，還是對於後繼者來說，這樣的代碼就算明了這句話是什麼意思，也是難於更改的。
後來我對這個模塊做了抽象，根據數據的特性做了三組線性映射，將四個函數抽象成兩個（一組Read/Write），並建立了一個統一的訪問模型，增加訪問許可權控制，精簡了參數列表（縮減為兩個參數，為基本數據類型）。即便如此，我也僅僅在某種程度上提高了可讀性。如果沒有完善的文檔來描述我的訪問模型，這個介面仍然是難於使用的，單單是閱讀文檔的時間其實幾乎是一樣的。
所以，我覺得離開項目本身只談可讀性是沒有意義的。這一點就像脫離項目需求而只追求程序本身的完美，也是沒有意義的一樣。
究竟是可讀性好些，還是運行期表現好些，還是要看你的代碼最終要被怎麼使用的。
這不是有明確答案的問題
