code cleanup: should fields, variables and properties be declared at the top or bottom of a class? [closed]

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 que开发者_如何学编程stion can be improved and possibly reopened, visit the help center for guidance. Closed 10 years ago.

Is it pretty common to declare it near the bottom in C# code?

I seen few example where its done that way.

There are tools like Resharper which help you organize your source code, does it have an option to specify where it should create regions for me?

---

This is a stylistic discussion because with the majority of compilers the placement at the top or bottom (of a class file) doesn't affect the results. Historically a lot of people do it at the top, but I like to leave them at the bottom.

Why?

Because once I've declared that member variable, I don't need to see it anymore - it shows up in my intellisense, so I don't need it in my face. When you open a file, you see the top - I want to see my code straight away, not a bunch of variable declarations. This is especially relevant because variable definitions are not a natively collapsible region in the VS editor, so if they're at the top you are forced to scroll past them. If I need to jump to it then Visual Studio's F12 or just a Ctrl+End will take me there.

This is a style that some may find hard to deal with initially, but it does grow on you quite quickly. This is a particularly good approach on files that are more mature. You will also find that if you are using a plugin like ReSharper it is smart enough to put generated declarations with all the others - which means if you have them at the bottom that's where ReSharper will put it. Of course this can get messy if you have multiple classes in a file, but if you do then variable definition placement is the least of your stylistic issues.

Edit:

at the risk of drifting off topic, a comment on using a #region block instead: I use regions all the time, I love them because they help me collapse code down out of the way. However using them requires discipline as it is easy for non-related code to make its way inside the region. How many times have you looked for code only to find it buried in a #region where it didn't belong?

---

I declare them at top. Try out StyleCop... I think it will give you a recommendation on that, and a million other style issues... its kinda cool... And you can disable rules you disagree with

---

My (late) five cents on this topic:

I like stateless programming. Before auto-implemented properties existed, the number of private fields in a class was a rough measure of its statefulness. That's why I preferred to keep them at the top to have a quick impression. For the same reason, now I like to keep auto properties grouped together at the top.

---

AFAIK there is no common convention. Some people prefer grouping the things logically: fields and the methods/properties operating with them go together. Others prefer putting public things on the top and private at the bottom.

What is really important, is that you use the style consistent with your team's style. Or, if there is no team style yet, try to convince the team to adhere to one (you'll need to persuade them that your style is better than no style).