Kotlin最被低估的优点之一是它可以减少项目中的文件数量。Kotlin文件可以包含多个/混合类声明、函数和枚举类等其他结构。这提供了许多Java没有提供的可能性。另一方面，它提供了一种新的选择——组织类和函数的正确方法是什么？
在《代码整洁之道》一书中，Robert C Martin打了报纸的比方。好代码应该读起来和报纸一样——高级结构在文件上部，越往下面越详细。这个文件应该讲述一个紧凑的故事。Kotlin的代码布局从这个比喻中可见一斑。
建议是——把相似的东西放在一起——放在更大的上下文里。
虽然Kotlin不会阻止你放弃“结构（structure）”，但这样做会使后续的代码导航变得困难。组织东西要以它们之间的关系和使用顺序为依据，例如：
enum class Topic { AUTHORIZE_REQUEST, CANCEL_REQUEST, DEREG_REQUEST, CACHE_ENTRY_EXPIRED } enum class AuthTopicAttribute {APP_ID, DEVICE_ID} enum class ExpiryTopicAttribute {APP_ID, REQ_ID} typealias onPublish = (data: Map<String, String?>) -> Unit interface IPubSub { fun publish(topic: Topic, data: Map<String, String?>) fun addSubscriber(topic: Topic, onPublish: onPublish): Long fun unSubscribe(topic: Topic, subscriberId: Long) } class RedisPubSub constructor(internal val redis: RedissonClient): IPubSub { ...}在实践中，通过减少为获得全貌而需要跳转的文件数量，可以显著减少脑力开销。
一个常见的例子是Spring JPA库，它使包变得混乱。可以把它们重新组织到同一个文件中：
@Repository @Transactional interface DeviceRepository : CrudRepository<DeviceModel, String> { fun findFirstByDeviceId(deviceId: String): DeviceModel? } @Repository @Transactional interface MachineRepository : CrudRepository<MachineModel, String> { fun findFirstByMachinePK(pk: MachinePKModel): MachineModel? } @Repository @Transactional interface UserRepository : CrudRepository<UserModel, String> { fun findFirstByUserPK(pk: UserPKModel): UserModel? }上述内容的最终结果是代码行数（LOC）显著减少。这直接影响了交付速度和可维护性。
我们统计了Java项目中移植到Kotlin的文件数量和代码行数。这是一个典型的REST服务，包含数据模型、一些逻辑和缓存。在Kotlin版本中，LOC减少了大约50%。开发人员在跨文件浏览和编写样板代码上消耗的时间明显减少。
简洁而富有表达力的代码编写简洁的代码是一个宽泛的话题，这取决于语言、设计和技术的结合。然而，Kotlin提供了一个良好的工具集，为团队的成功奠定了基础。下面是一些例子。
类型推断类型推断最终会减少代码中的噪音。这有助于开发人员关注代码的目标。
类型推断可能会增加我们跟踪正在处理的对象的难度，这是一种常见的担忧。从实际经验来看，这种担忧只在少数情况下有必要，通常少于5%。在大多数情况下，类型是显而易见的。
下面的例子：
LocalDate date = LocalDate.now(); String text = "Banner";变成了：
val date = LocalDate.now() val text = "Banner"在Kotlin中，也可以指定类型：
val date: LocalDate = LocalDate.now() val text: String = "Banner"