|
That's what she said.
|
|
|
|
|
I'm a C#/WPF guy, and every single one of my classes is coded as follows:
I use regions, and I have the following regions always in this order (assuming there's code there for it):
Constants
Event Declarations
Private Fields
Properties
Dependency Properties
Commands
CTOR
Public Methods
Method Overloads
Private Methods
Event Handlers
In each one of these sections, the items are always in alphabetical order. Why? because when you come in after me and open one of my classes, knowing I code this way, you'll always know where the piece you're looking for is.
I never put code in an event handler, except a call to a private method. Why? Assume you have a bunch of code in a ListBox SelectedItem event. Then you change ListBox to a ComboBox... now you have a bunch of code to do. For a button click.. you're almost certainly going to do multiple things, and all that code doesn't belong in MyButton_Click.
I always correct spelling errors. Why? because I'm not lazy and leaving it is just wrong.
I always use XAML comments. Why? So when you use my class you'll know what things do.
I always comment where appropriate, and I always keep comments current. Why? You already know why.
When a class is finished, I always remove and sort namespace usings. Why? Less code is better.
Now this is just me... I'm anal like this. What about you? I'm curious how other people code.
If it's not broken, fix it until it is
|
|
|
|
|
Yes.
Kevin Marois wrote: XAML comments
Kevin Marois wrote: Less code is better.
Sure, but that doesn't mean "fewer keystrokes" is better (some practitioners (even language designers) don't seem to understand that). A statement should be as informative to the reader as possible. You only write it once, but it's read many times, so don't be lazy up front.
modified 1-Aug-15 20:58pm.
|
|
|
|
|
I simply meant that I remove unused code. If a namespace is inserted, then not used, remove it.
Same with commented out code. If it's truly deprecated, the remove it.
If it's not broken, fix it until it is
|
|
|
|
|
Kevin Marois wrote: Same with commented out code. If it's truly deprecated, the remove it.
Right on! Besides, you can always get that code back since you're using a Version Control System.
Uh... you are using a VCS, right? Rrrrr...iiight?
I'm sure you are, OP. It's the others who leave their deadwood code in that I don't trust.
|
|
|
|
|
+1 Kevin for removing commented out code
We can’t stop here, this is bat country - Hunter S Thompson RIP
|
|
|
|
|
Agreed 100%.
I view my source code as a representation of myself. I would hate to have another developer scratch their head to figure out what my code does. My choice of #region ordering is slightly different, but it's the same in principle.
/ravi
|
|
|
|
|
Some people can't stand regions.. I don't understand that at all. Why in the world would I want to keep looking at dozens or hundreds of lines of code I don't need to see.
If it's not broken, fix it until it is
|
|
|
|
|
Kevin Marois wrote: Why in the world would I want to keep looking at dozens or hundreds of lines of code I don't need to see. Exactly. I find code folding to be a helpful editor feature. I also use it in Android Studio (which supports //region and //endregion tags).
/ravi
|
|
|
|
|
I use regions occasionally. What I don't like (in C#) is that regions appear as compiler directives when they actually have no affect on the compiler, only on some (not all) text editors. But that doesn't keep me from using them when appropriate.
And I think defining regions based on purpose, rather than type is likely to provide greater value to the reader.
I prefer to split classes up into smaller files as appropriate -- to separate large chunks, such as features and whatnot. Huge monolithic class files are a poor design choice (and was flabbergasted when I found that C# v1 enforced it!) in my opinion. It is to be hoped that smaller files make working with a code management system simpler -- less branching and merging as there should be less need for multiple developers to work on the same file at the same time for instance. I don't care how good your merge engine is, the best merge engine is one you don't need to use.
|
|
|
|
|
If you keep your classes small, then the Region declarations just become noise. Smaller classes are better at hiding the hundreds of lines of code you don't need to see as well.
|
|
|
|
|
Amen! There must a correlation between lines of code per abstraction and the likelihood of heart failure in the near future.
|
|
|
|
|
Kevin Marois wrote: Some people can't stand regions I added the "Collapse to Definition" button to the toolbar, this collapses my VM code to Properties and Methods, I use nested regions - a LOT
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
I'm pretty organized but not to that extent.
New version: WinHeist Version 2.1.1 new web site.
I know the voices in my head are not real but damn they come up with some good ideas!
|
|
|
|
|
|
This message was taken by the moderation filter. You should have said you are klingon
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
All you know I am Klingon.
|
|
|
|
|
Not at all.
Gobs of commented out blocks of code that I am to paranoid to delete.
Gotos wherever I see fit.
Indents that I'll fix someday..
Global variable festival.
And it goes on.
|
|
|
|
|
Ron Anders wrote: Gotos wherever I see fit.
Global variable festival.
/ravi
|
|
|
|
|
Ron Anders wrote: Global variable festival.
Brilliant !
|
|
|
|
|
I do nearly* all this, notably excepting the Region declarations - but I do have my code sorted by "types" (Constants, Events, etc.) and alphabetically as a sub-sort. I tend to keep my classes very small and single responsibility (SOLID code), so at that point the Region declarations just become boilerplate noise that gets in the way.
Resharper does nearly all of this sorting and cleanup for me, so it makes it easy to keep my code classes clean.
*I put the XML comments on all public items, but only on less accessible items if there seems to be a need for it. Well named functions usually obviate the need for the XML comment on these.
|
|
|
|
|
I detest regions, but other than that, yes, I have a structure of each file and class that I adhere to, etc.
The fact that you do these things seems really rare to me. I have experienced such horrid code formatting. I keep getting the "ah, so this is why I work for myself and on projects where I'm the only developer" reinforcement, because everywhere I look, I see sh*t.
Marc
|
|
|
|
|
I use region to group related method and property usually 1~4 of them or about 100 - 1000 lines.
And I name the region with contained method / property. I don't understand why people use useless 'public method' 'private method' 'property' it bother me greatly to have a huge public region with all public method, I prefer smaller thematic region. Particularly when you have to navigate back and forth between public and private method region to understand a method. I try to make it so that when one look at a region, one can known everything there is to know about that block of code without having to look elsewhere.
Hence I also put my field declaration near the related method / property. it bother me to have to hunt for a field declaration in another region.
I correct spelling error most of the time..
Never use XAML comment
I don't comment much. Often 1 or few line of code comment on method. sometimes 1 or a few line before non obvious algorithm. Certainly NO obvious comment.
I remove and sort namespace .. occasionally..
|
|
|
|
|
you sick sick man
MCAD
---
|
|
|
|
|
I hope I'm not too late to be in the contest: [^]
This is the "Agitation Police Dog" Model from All-K9.com.
cheers, Bill
«I want to stay as close to the edge as I can without going over. Out on the edge you see all kinds of things you can't see from the center» Kurt Vonnegut.
modified 2-Aug-15 5:49am.
|
|
|
|