问题标签 [coding-style]

出于某种原因，我从来没有看到这样做过。有理由不这样做吗？例如，我喜欢 _blah 作为私有变量，并且至少在 Windows 窗体中，控件默认是私有成员变量，但我不记得曾经见过它们以这种方式命名。在我在成员函数的局部变量中创建/存储控制对象的情况下，有一些视觉区别特别有用。

在 php 中，我经常需要使用数组来映射变量……但我似乎无法在一个内衬中做到这一点。cf 示例：

这是一个小问题，但它每隔一段时间就会出现问题......我不喜欢这样一个事实，即我没有使用变量；）

假设您要输出或连接字符串。你更喜欢以下哪种风格？

• var p = new { FirstName = "Bill", LastName = "Gates" };

• Console.WriteLine("{0} {1}", p.FirstName, p.LastName);

• Console.WriteLine(p.FirstName + " " + p.LastName);

您更愿意使用格式还是简单地连接字符串？什么是你最喜欢的？其中之一会伤害你的眼睛吗？

你有任何合理的论据来使用一个而不是另一个吗？

我会去第二个。

这里有人知道好的批处理文件代码缩进器或美化器吗？

专门针对 PHP、JS 和 SGML 语言。

最好有样式选项。

继我最近关于大型复杂对象作为 Web 服务结果的问题之后。我一直在考虑如何确保所有未来的子类都可序列化为 XML。

现在，显然我可以实现IXmlSerializable接口，然后将读取器/写入器扔给它，但我想避免这种情况，因为这意味着我需要在任何时候实例化读取器/写入器，并且 99.99% 的时间我将使用一个字符串，所以我可以自己写。

但是，要序列化为 XML，我只是用Xml 装饰类及其成员？？？属性（XmlRoot，XmlElement等），然后将其传递给XmlSerializer和StringWriter以获取字符串。这一切都很好。我打算将返回字符串的方法放入通用实用程序方法中，所以我不需要担心类型等。

这与我有关的是：如果我不使用所需属性装饰类，则直到运行时才会引发错误。

有没有办法强制属性装饰？这可以用 FxCop 完成吗？（我还没用过 FxCop）

更新：

很抱歉耽搁了这些家伙，还有很多事情要做！

绝对喜欢在测试用例中使用反射而不是诉诸 FxCop（喜欢将所有东西放在一起）的想法。Fredrik Kalseth 的回答非常棒，感谢您包含代码，因为它可能会让我有点挖掘弄清楚如何自己做！

+1 给其他人提供类似的建议:)

我想参考在开发 PHP 应用程序时使用包含文件与对象（类）的优缺点。

我知道我会受益于有一个地方可以回答这个问题......我有一些自己的意见，但我期待听到其他人的意见。

一个简单的例子：

我网站上的某些页面仅供登录用户访问。我有两个实施选项（还有其他选项，但我们只限于这两个）

1. 创建一个 authenticate.php 文件并将其包含在每个页面上。它包含身份验证的逻辑。

2. 创建一个具有身份验证功能的用户对象，在每个页面上引用该对象进行身份验证。

编辑 我希望以某种方式权衡一种方法的好处。我目前（和较弱的原因）如下：

包括 - 有时一个函数只是更容易/更短/更快地调用对象 - 功能和属性的分组导致长期维护。

包括- 编写更少的代码（没有构造函数，没有类语法）叫我懒惰，但这是真的。

对象- 强制形式和功能和创建的单一方法。

包括- 新手更容易处理对象 - 新手更难，但专业人士不赞成。

我在项目开始时会查看这些因素，以决定是否要包含或对象。这些是我脑海中的一些优点和缺点。

我很好奇其他人如何使用this关键字。我倾向于在构造函数中使用它，但我也可以在整个类中的其他方法中使用它。一些例子：

在构造函数中：

别处

我必须在一个大型的、旧的、意大利面条式的 ASP 系统中做一些重要的开发。我已经离开 ASP 很长时间了，我将精力集中在 Rails 开发上。

我采取的一个基本步骤是将页面重构为具有有意义名称的子程序和函数，这样至少在文件顶部很容易理解通常发生的事情。

ASP 有没有值得的 MVC 框架？或者如何至少从视图中获取业务逻辑的最佳实践？（我记得那天做了很多包含——这仍然是这样做的方式吗？）

我也很想对业务逻辑进行一些单元测试，但也许我要求太多了？

更新：

项目中有超过 200 个 ASP 脚本，大约有数千行；）哎呀！

我们可能会选择“大改写”，但在那之前，当我在更改页面时，我想花一点额外的时间来清理意大利面。

HTML 标准定义了 CSS（表示）和 HTML（语义或结构）之间的关注点的明确分离。

是否有人使用 CSS 和 XHTML 的编码标准文档，其中包含有助于保持这种分离的条款？在这样的编码标准文档中包含哪些好的条款？

与Regular cast vs. static_cast vs. dynamic_cast相关的问题：

你更喜欢 C++ 中的哪种强制转换语法风格？

• C 风格的强制转换语法：(int)foo
• C++ 风格的强制转换语法：static_cast<int>(foo)
• 构造函数语法：int(foo)

它们可能不会翻译成完全相同的指令（是吗？），但它们的效果应该是相同的（对吧？）。

如果您只是在内置数字类型之间进行转换，我发现 C++ 风格的转换语法过于冗长。作为一名前 Java 编码员，我倾向于使用 C 风格的强制转换语法，但我当地的 C++ 大师坚持使用构造函数语法。

你怎么看？