我是一名近期毕业的AI专业研究生（大约2年），在一家规模适中的公司工作。由于我是部门内第一个采用新技术的人，所有基础（可读性高？）C#编码标准文件的制作任务落到了我的手上。
我想我应该解释一下，我可能是最初级的软件工程师，但我很期待这个任务，因为希望我能够真正做出一些有用的东西。我已经在互联网上进行了相当广泛的搜索，并阅读了有关编码标准文件应该 / 不应该包含什么的文章。这似乎是任何地方都可以寻求建议的好地方。
我意识到我可能正在打开一个关于“最佳操作方法”的争论之门。我既理解又尊重每位程序员都有其喜好的事实，也因此不会写任何过于严格规定的文件来限制个人风格，而是尝试获得一般方法和商定的标准（例如命名规则），以帮助使个人的代码更易读。
那么开始吧...有什么建议吗？无论如何？
具有讽刺意味的是，设定实际标准可能是相对容易的。
我首先建议从其他工程师那里征求意见，了解他们认为应该包括哪些内容以及他们认为重要的指南。强制执行任何类型的准则都需要人们的支持。如果你突然给他们一个规定如何编写代码的文件，无论你是最初级的还是最资深的人，都会遭到抵抗。
在提出了一系列提案后，将它们发送给团队进行反馈和审查。再次获得所有人的支持。
已经存在非正式的编码惯例（例如前缀成员变量、驼峰命名法），如果这种惯例存在，并且大多数代码符合它，那么正式化它的使用是值得的。采用相反的标准会带来比它所值得的更多的麻烦，即使它是普遍推荐的。
考虑重构现有代码以符合新的编码标准也很值得。这看起来可能是浪费时间，但是不符合标准的代码可能会起到反作用，因为您将拥有各种风格的大杂烩代码。它也会让人陷入困境，是否应该让某个模块中的代码符合新的标准或者遵循现有代码风格。
在制定编码标准和最佳实践方面，我一直使用Juval Lowy的pdf作为参考。这个标准非常接近于FxCop/Source Analysis，这是另一个宝贵的工具，可以确保遵循标准。通过使用这些工具和参考资料，您应该能够制定出一个漂亮的标准，所有开发人员都不会介意遵循，并且能够强制执行。
这两点是我的愿望的现实，即每个人都编写相同的代码。
我刚刚开始在一个要求使用m_表示成员变量，p_表示参数以及类型前缀的编码标准中工作。例如，字符串类型可以用'str'表示。
因此，在方法体中可能会出现这样的代码：
m_strName = p_strName;
很糟糕。真的很糟糕。
p_strName中的子字符串——当你被迫使用这种可怕的东西时，它可以让你少受10%的痛苦。:o - Sam Harwell