coding-style

问题 Recently saw someone commending another user on their use of sizeof var instead of sizeof(type). I always thought that was just a style choice. Is there any significant difference? As an example, the lines with f and ff were considered better than the lines with g and gg: typedef struct _foo {} foo; foo *f = malloc(count * sizeof f); foo *g = malloc(sizeof(foo) * count); foo **ff = malloc(count * sizeof *ff); foo **gg = malloc(sizeof(foo*) * count); In my opinion, the first set is just a

问题 I was thinking: they say if you're calling destructor manually - you're doing something wrong. But is it always the case? Are there any counter-examples? Situations where it is neccessary to call it manually or where it is hard/impossible/impractical to avoid it? 回答1: Calling the destructor manually is required if the object was constructed using an overloaded form of operator new() , except when using the " std::nothrow " overloads: T* t0 = new(std::nothrow) T(); delete t0; // OK: std:

问题 As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 8 years ago . I noticed some people use the following notation for declaring pointer variables. (a) char* p; instead of (b) char *p; I use (b). What

问题 My style of coding includes the following idiom: class Derived : public Base { public : typedef Base super; // note that it could be hidden in // protected/private section, instead // Etc. } ; This enables me to use "super" as an alias to Base, for example, in constructors: Derived(int i, int j) : super(i), J(j) { } Or even when calling the method from the base class inside its overridden version: void Derived::foo() { super::foo() ; // ... And then, do something else } It can even be chained

问题 The way I do 80-column indication in Vim seems incorrect: set columns=80 . At times I also set textwidth , but I want to be able to see and anticipate line overflow with the set columns alternative. This has some unfortunate side effects: I can't set number for fear of splitting between files that have different orders of line numbers; i.e. < 100 line files and >= 100 line files will require two different set columns values because of the extra column used for the additional digit display. I

问题 The way I do 80-column indication in Vim seems incorrect: set columns=80 . At times I also set textwidth , but I want to be able to see and anticipate line overflow with the set columns alternative. This has some unfortunate side effects: I can't set number for fear of splitting between files that have different orders of line numbers; i.e. < 100 line files and >= 100 line files will require two different set columns values because of the extra column used for the additional digit display. I

问题 Closed. This question is off-topic. It is not currently accepting answers. Want to improve this question? Update the question so it's on-topic for Stack Overflow. Closed 6 years ago . It looks quite easy to find such a tool for Java (Checkstyle, JCSC), but I can't seem to find one for C/C++. I am not looking for a lint-like static code analyzer, I only would like to check against coding standards like variable naming, capitalization, spacing, identation, bracket placement, and so on. 回答1: The

问题 I have a coworker who is actively trying to convince me that I should not use do..end and instead use curly braces for defining multiline blocks in Ruby. I'm firmly in the camp of only using curly braces for short one-liners and do..end for everything else. But I thought I would reach out to the greater community to get some resolution. So which is it, and why? (Example of some shoulda code) context do setup { do_some_setup() } should "do somthing" do # some more code... end end or context {

问题 I often see JavaScript code which checks for undefined parameters etc. this way: if (typeof input !== "undefined") { // do stuff } This seems kind of wasteful, since it involves both a type lookup and a string comparison, not to mention its verbosity. It's needed because undefined could be renamed, though. My question is: How is that code any better than this approach: if (null != input) { // do stuff } As far as I know, you can't redefine null , so it's not going to break unexpectedly. And,

问题 Is there any tools like StyleCop for SQL Server? We need the same features of StyleCop (enforce a set of style and consistency rules). [Additional Feature]: Integration with SQLServer Management Studio would be cool. 回答1: There is SSW's SQLAuditor [There's also the SQL Server 2008 R2 Best Practices Analyzer but that has more of a DBA focus] 来源： https://stackoverflow.com/questions/3202887/stylecop-equivalent-for-sql-server