假设一个项目长时间使用C类前缀,并且在后期更改是浪费时间,并且最初编写样式指南的人已被击中通过总线,代码中没有结构......
这是一个非常简单的问题,但如果一个C ++代码风格指南说“使用C作为类名前缀”那么这应该也意味着也使用C作为结构前缀,或者我们应该使用不同的东西,比如S示例
class CFoo { };
struct CBar { };
......或......
class CFoo { };
struct Bar { };
答案 0 :(得分:27)
简单回答 - 不要为类使用C前缀。这是最无意义的匈牙利符号。现在可能是重写风格指南的时候了。坦率地说(并且作为写了几个东西的人说话),大多数这样的指南都是垃圾和/或很久很久以前写的,从未更新过。
答案 1 :(得分:13)
如果样式指南没有指定,我会(可能)使用“结构是所有成员公共的类”-rule来使用C作为结构,是的。或者我会想“呃,这是一个可以解决这个愚蠢的初始规则的漏洞,但是”并没有使用它。换句话说,这是非常主观的。
答案 2 :(得分:5)
如果代码样式指南未指定,请查找一直遵循样式指南的代码,并查看已完成的内容。
如果样式指南中没有代码,请与参与项目的所有人达成协议。
如果没有其他人参与该项目,只需决定并保持一致。
答案 3 :(得分:3)
我认为这条准则很愚蠢而且令人困惑。事实上你不得不提出这个问题证明了这一点。
编码样式旨在提高可读性;很明显,如果一个标识符是一个类,或者没有,特别是如果你使用带有鼠标悬停工具提示的体面IDE。
答案 4 :(得分:2)
我们通常对类没有C前缀,对于没有方法的结构使用T前缀(即“C”结构)。
答案 5 :(得分:2)
对我来说,这将归结为:
您是否希望代码的读者能够立即区分两种声明类型?
虽然前缀的使用通常令人反感,但请仔细考虑代码维护者的视图。对他们来说,思考是否有帮助,“啊!没有C前缀,这是一个结构”。使用结构而不是类可能意味着代码中的特定内容。如果没有,为维护者继续使用前缀更有意义。
答案 6 :(得分:2)
如果样式指南不能达到促进易读性,一致性和正确性的目的,则应对其进行修改,直到它出现或抛入循环文件(垃圾桶)。
此外,如果人们不遵循它,那么它应该更新,以便更容易遵循(或修改工具,以便更容易编码到guidline)。
答案 7 :(得分:0)
根据C为类添加前缀的现有模式,您应该为S加前缀为struct,将I作为接口。
此外,前缀E表示枚举,D表示委托,D表示目录,F表示功能/方法,F表示文件,F表示字段,N表示命名空间,P表示页面,P表示参数,P表示属性,R表示返回值,v表示变量。
截至变量,前缀为
实施例
○:
namespace NGqqnbig.NConsoleApplication1
{
class CProgram
{
static void Main(string[] pasArgs)
{
FMain(pasArgs);
}
static void FMain(string[] pasArgs)
{
var vsLine= CConsole.FReadLine();
var viSVN= CConvert.FToInt32(vsLine);
var occCVC = new CCCCVC();
occCVC.PICVC = viSVN;
}
}
class CCCCVC
{
private int fiCVC;
public int PICVC
{
get { return fiCVC; }
set { fiCVC = pivalue; }
}
}
}
为:
namespace Gqqnbig.ConsoleApplication1
{
class CProgram
{
static void Main(string[] args)
{
var line= Console.ReadLine();
var svn= Convert.ToInt32(line);
var cardVerificationCode = new CreditCardVerificationCode();
cardVerificationCode.VerificationCode = svn;
}
}
class CreditCardVerificationCode
{
public int VerificationCode { get; set; }
}
}