如果你在团队中，格式一定要团队一起决定，然后每个人都去遵从同样的格式，这样在阅读时才不会感觉吃力。约定格式用不了多长时间，大概十分钟就能完成约定，包括缩进、命名方法、注释方法等。
代码格式很重要，不可忽略，必须严肃对待。代码格式关乎沟通，而沟通是专业开发者的头等大事。或者你认为“让代码能工作”才是专业开发者的头等大事。然而这是不对的，你今天编写的功能，极有可能在下一版本中被修改，但代码的可读性却会对以后可能发生的发生的修改行为产生深远影响。原始代码修改之后很久，其代码风格和可读性仍会影响到可维护性和扩展性。即使代码已不复存在，你的风格和律条仍存活下来。
什么样的书写格式比较好呢？
1） 向报纸学习，报纸会用大字体给出一个标题，然后标题下第一段文字会有一段概述，再往下才是详细描述。源文件也要像报纸文章那样，名称应当简单且一目了然。名称本身应该足够告诉我们是否在正确的模块中。源文件最顶部应该给出高层次概念和算法。细节应该往下渐次展开，直至找到源文件中最底层的函数和细节。前面我们讲过应该给函数分出抽象层级，抽象层级越高，越接近用户语言描述，应该放在顶部，抽象层级越低，越接近底层实现，应放在后面。可能的话，抽象层级高的才设为公有，抽象层级低的应尽量设为私有。像报纸文章一般，我们指望最重要的概念先出来（抽象层级高的），指望以包括最少细节的方式表述它们。我们指望底层细节最后出来。这样，我们就能扫过源代码文件，自最前面的几个函数获知要旨，而不至于沉溺到细节中。
2） 可以利用代码的疏密表现出“功能模块”，功能集中的代码之间不要插入空行，而功能分散，相对独立的代码应用空行来进行分隔，加上函数应该尽量短小的原则，从而在视觉上一眼能看出功能的逻辑分布。
3）功能相关的函数应该放到一起，例如前面一个抽象层级高一些的函数，内部调用了一个抽象层级低的函数，应在抽象层级高的函数之后紧跟着抽象层级低的被调用函数，形成一个自顶向下贯穿模块的良好信息流。应避免在类中摸索，从一个函数跳到另一个函数，上下求索，中断思绪。
4）每个程序员都有自己喜欢的格式规则，但如果在一个团队中工作，就是团队说了算。一组开发者应当认同一种格式风格，每个成员都应该采用那种风格。我们想要让软件拥有一以贯之的风格。我们不想让它显得是由一大票意见相左的个人所写成。