问题标签 [conventions]

当我承担任何复杂的 R 项目时，我的脚本很快就会变得冗长和混乱。

我可以采用哪些实践来使我的代码始终令人愉快地工作？我正在考虑类似的事情

• 在源文件中放置函数
• 何时将某些内容分解为另一个源文件
• 主文件中应该包含什么
• 使用函数作为组织单位（考虑到 R 使得访问全局状态变得困难，这是否值得）
• 缩进/换行实践。
  • 对待（像 {?
  • 将 )} 之类的内容放在 1 行或 2 行上？

基本上，您组织大型 R 脚本的经验法则是什么？

__str__()当你应该实现vs时是否有 python 约定__unicode__()？我看到类覆盖__unicode__()的频率高于__str__()但它似乎并不一致。是否有具体的规则，什么时候实施一个比另一个更好？两者都有必要/良好的做法吗？

Stackoverflow 上有几个问题，关于是否有任何研究或研究什么是最好的编码约定/风格。这不是这个问题的目的。这个问题是关于是否有任何研究研究拥有组织范围的编码约定和风格是否有任何优势、生产力提高或其他积极的副作用。

对此我有自己的看法，基本上就是制定这样的标准有巨大的好处。老实说，我不在乎我需要使用什么样式，只要它在我可能必须使用的所有代码中都是一致的。

我只是想知道是否有任何研究支持我的观点或与之相矛盾。

我经常使用 Python 编写代码，并且经常创建类。现在，我不确定这是否是好的 Python 形式，但我只是在与 main() 相同的文件中声明了一个类。

我想知道在Java中做同样的事情是否是好的形式？

例如，

不会在 Eclipse 中抛出错误，因此必须允许。但是这样做可以吗？在单独的文件中声明这个类会更好吗？

编辑：我只是想强调一下，我的新类实际上只是一个容器，可以多次保存相同类型的数据，而且实际上只有 3 个值。所以总共大约 5 行代码。问题是 - 这值得一个新文件吗？

正如在各种 MVC问题和博文中所讨论的那样，我们知道 ASP.NET MVC 项目布局非常注重惯例。

我一味的在文件夹里做了一个子目录Controllers。

这感觉不对。

替代文字 http://www.imagechicken.com/uploads/1252003002097179400.png

问题：关于存储 ViewModel 的目录的公认约定是什么？您有什么建议或既定惯例是什么？

您认为在代码中编写字典文字时最常用的约定是什么？

我会写一个可能的约定作为答案。

我的应用程序是上下文敏感的，我为主窗口/上下文/弹出窗口和其他地方动态构建菜单。我通常知道给定的菜单命令在应用程序的当前状态下是否有效。禁用/灰色当前不适用的菜单选项是更好的做法，还是因为无论如何我都在生成菜单，所以完全忽略它们？

该应用程序是 Java/Swing，任何人都很好奇。这个问题似乎与 GUI 工具包无关，但可能与平台有关。

我试图找到一个资源来显示 Fluent NHibernate 使用的默认约定，而没有应用自定义（用户）约定。

谢谢！

我知道有关于同一主题的问题，但对于 HTML。关于在 Flex 应用程序中使用外部样式表有哪些好的约定？您将如何分解样式表（样式表的名称及其包含的内容）？

假设我有一个巨大的输入表单，当然代表类。我需要将此输入加载到类的实例中。这个输入显然包含（一些非常复杂的验证）检查，显然逻辑层已经包含了那些输入验证。问题是我在用gui做什么。

我是否应该以一种非常丑陋的方式在 GUI 中重写所有这些验证？

或者我应该在逻辑层中编写一些静态方法，在 gui 和逻辑层中使用这些方法，但仍然创建验证自身的重复（首先 gui 验证自身，然后逻辑验证发送给它的内容)

或者我应该假设 gui 没问题，用 try 块包围使用逻辑层的相关代码，然后，如果抛出异常，通知用户有些事情是不正确的（不给他机会知道什么它是）

或者我应该公开异常，以这种方式向他公开参数、类和命名空间名称，他可能不会理解。

或者我应该为每个错误创建一个特殊的异常类，这样可以准确地告诉用户问题是什么，但可能会创建数百个可能的异常

还是我应该将它与一般异常分开，每个人都包括枚举描述错误的确切内容，然后捕获这些异常，并通过检查枚举告诉用户究竟是什么问题，但通过捕获所有不必要的异常使应用程序更重时间。

或者我应该（有人向我提供了这个，这不是我的想法，不要对我大喊大叫:D）来验证逻辑层中的输入，并且只在 gui 中检查它（似乎是我绝对可怕解决方案：D）

还有更重要的问题——我应该在哪里学习这些东西？通常我的直觉很好，但我不想不必要地发明轮子..（我很确定你每天都在轰炸这些基本的东西）。

非常感谢！