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），并建立了一个统一的访问模型，增加访问权限控制，精简了参数列表（缩减为两个参数，为基本数据类型）。即便如此，我也仅仅在某种程度上提高了可读性。如果没有完善的文档来描述我的访问模型，这个接口仍然是难于使用的，单单是阅读文档的时间其实几乎是一样的。
所以，我觉得离开项目本身只谈可读性是没有意义的。这一点就像脱离项目需求而只追求程序本身的完美，也是没有意义的一样。
究竟是可读性好些，还是运行期表现好些，还是要看你的代码最终要被怎么使用的。
这不是有明确答案的问题
