显式导入自然会导致更好的代码组织

这暴露了另一个问题。

Main.elm中完全没有涉及Controller类型的功能,并且恰好在Controller模块中。

当我们将“ updateContoller”移动到Controller.elm时,我们看到它变成了一个更精简的版本。 假设其类型和功能来自同一文件会更安全。

再往前推一点( 借助 Elm-Lens ,一个Atom插件 )…

我们看到“ calculateControllerStateFromGamePad”功能不再在控制器模块外部使用。

现在可以修改Controller模块公开的类型和功能,以将“ calculateControllerStateFromGamePad”和“ calculateControllerStateFromKeyboardState”替换为“ updateController”。

代码的组织方式以及与之交互的方式实际上只是同一枚硬币的两个方面。

这是另一个例子。

case语句的返回值是一个元组,其值被破坏为“ camera”和“ gameScene”

这也位于Main.elm文件中。 “ gameSize”从哪里来?

它似乎没有传递给“ viewBody”函数或由其计算。 那是一个常数吗? 还是在Main.elm中定义的函数?

从另一个导入中删除“暴露”部分后…

显然,“ gameSize”是来自“坐标”模块的常量。

同样重要的是,这种明确性可能会帮助提示类似的问题,“坐标模块是gameSize常量存在的正确位置吗?”

即使没有明确的答案,这些问题也可以导致更好的组织和对我们解决方案的更好表示。

结论

删除导入声明的公开部分可以提高可读性。 错位代码变得更容易发现,并且选择应该公开的模块变得更加清晰。