【问题标题】:The best strategy with headers and function prototypes带有标头和函数原型的最佳策略
【发布时间】:2014-10-15 14:30:30
【问题描述】:

在 C 方面相对较新,我需要完成自己的大型 C 项目。所以我将定义风格。我试图找出达成交易的最佳策略是什么 带有标题和函数原型。我一直在寻找信息..但一切似乎都很模糊。

所以我问。根据您在大型 C 项目中的经验,有什么更好的方法?

  1. 有一个带有函数原型的大标题,并包含在那里 就在我添加功能时的所有原型 + 可能是结构声明的单独标头 + 一些具有结构实现的 *.c 文件,其中类似的功能将是 分组。

  2. 拥有带有原型和结构的单独头文件(foo.h) 每个 *.c 文件 (foo.c) 的声明

  3. 通过使用一个巨大的 *.c 文件来尽量减少原型的使用,并不断地相对于其他函数移动以避免原型 可能的话?

【问题讨论】:

  • 总的来说,我投票给#2。模块化使您的代码更易于维护,尤其是随着项目的发展。

标签: c


【解决方案1】:

第二个选择是典型的,通常被认为是最好的。

理论上,将事物分解为模块可以加快编译速度,因为您无需重新构建未更改的代码,您只需链接现有的目标文件即可。

实际上链接可能不是瓶颈,但从概念上讲,根据代码的作用将代码分解为模块是很好的。厨房里所有东西的大汤并不总是很好吃。

【讨论】:

    【解决方案2】:

    第一个解决方案可以工作,但会阻止模块化和代码在其他项目中的重用。

    第二个是我和可能许多 C 程序员会推荐的。它允许快速编译项目,因为只需要重新编译更改的文件,并且可以提供最佳的模块化。

    第三个文件非常大且无法维护。

    【讨论】:

      【解决方案3】:

      选择二是首选方法,并且有充分的理由:

      1) 模块化 - 一个较小的文件,其中包含支持共同目的的功能。
      2) 可维护性 - 如果需要,其他人更容易查看、理解和编辑较小的文件。
      3) 代码重用 - 编写良好的模块可以在许多项目中重用

        eg, a logging.c and logging.h, can be easily dropped into any project  
        while everything.c and everthing.h would be useless in a new project
      

      4) 构建效率。 - 模块,如果未更改,则不需要在构建期间重新编译。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 2013-04-13
        • 1970-01-01
        • 2012-04-25
        • 2014-06-26
        • 2017-08-05
        • 1970-01-01
        • 2010-09-06
        相关资源
        最近更新 更多