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 13 years ago.
For me, No.1 has to be code folding.
#region xxx
#endregion
All of sudden, people find an excuse to have big classes(files) because they can "organize" them nicely. I once saw a half-page-long class with 3,000 lines. I was speechless and they were like "what's the problem"?
No.2 is partial class. It's actually a nice feature especially when you work with generated code. However, some people use it to "break down" a class to multiple pieces. Why? Because that class is so big and popular that it's always locked in the source control. Instead of breaking down the class into different smaller classes, they create multiple files like my_Class1.cs, your_Class1.cs etc so that people can work on Class1 at the same time.
I would like to include "Copy&Paste" but it's not Visual Studio's fault...
Next to #region blocks I would say the ASP.NET IDataSource implementations (SqlDataSource, LinqDataSource) that force (allow) you to write data-access code directly into your aspx pages. I would not use this even for a really small demo app, but nowhere in the documentation of these classes is it mentioned that for a well-designed application you should not use these classes.
I think the most abused feature would be using the default templates as is. Many of the templates include "partial" as well as the regions and include/using statements that aren't required by the code inside of the class.
After that, I'd have to agree with the #region blocks; however, those CAN be useful if done properly. Usually though they are used as a means to organize classes that are larger than they probably should be.
Not paying attention to Warnings
Graphical editor for WebForms. Spoiled so many potentially good developers into drag-and-drop monkeys.
Related
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 10 years ago.
Unfortunately, C# does not have anything like C++'s friend. Hence, for instance, in order to solve something like the classic matrix/vector multiplication example (where efficiency can be gained by befriending matrix and vector, such that each class has access to the private members of the other), I have to define the class members internal.
Now I know myself, and improper encapsulation will lead to messy code, sooner or later. Hence I would like to keep the internal universe as small as possible.
This will lead to very small assemblies.
Does that have any drawbacks, or doesn't that matter?
Answer to question in the title: how small assembly should be?
There is no particular requirements or recommendations on size of assemblies*.
*Insane number of assemblies (probably in thousands) in theory may slow down loading due to need to lookup information in more places.
When picking size consider:
proper encapsulation
ease of editing (large number of solutions vs. several large one both have drawbacks and benifits at build/edit/deploy time)
technical restrictions (like GAC deployment, partially trusted code, anyCPU/x86/x64 requirements)
If you don't like internal cause it's too open (to the rest of your api), make those classes that need to be open to eachother a separate microassembly containing just this small set of classes. You can always embed that assembly in your main api-assembly.
That should both keep your classes open to eachother, and not let anybody else in (unless they blatantly ignore your assembly-structure, and place more stuff in your helper-assembly than its name implies it should contain. But who would do such a thing?! :)
Unless I don't understand:
Unfortunately, C# does not have anything like C++'s friend.
Friend Assemblies (C# and Visual Basic) does exist. It may not be exactly what C++ has, but it sounds like it would work.
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 10 years ago.
I've recently been tasked with pulling together 4 independent developers at my company into a cohesive team that generates similar (and good) code as a team.
We're implementing the use of iDesigns C# coding standard which will help our code look similar, and does give some implementation guidelines, but is there a general standard, rules of thumb (Top 10) out there for how code should be built, what every class should 'have' or 'do'?
I read this article by John Connelly about implementation practices, but am not having much luck in finding more references on the subject.
Is there a Implementation 'standard' out there for c# classes/projects? or is it such a broad subject that it can't be defined?
My favorites:
http://csharpguidelines.codeplex.com/releases/view/46280
Microsoft's Design Guidelines for Developing Class Libraries
StyleCop
Although it isn't a standard as such, I'd strongly recommend considering the use of StyleCop. It's a highly customizable Visual Studio plugin that allows you to easily enforce coding standards. Additionally it can be integrated into your cruise control server build, so that if any of those standards aren't adhered to, it breaks the build.
A very useful little tool, that at first I hated, but now I love.
The only C# standard C# has is the "Standard ECMA-334 C# Language Specification". Anything beyond that is up to the developer to do as they wish as they code their program.
Now there are some good rules of thumb to follow (like the two you referenced) but they are just rules of thumb. As long has the entire team is consistent with each other you can do whatever you want as a "standard".
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 10 years ago.
I've heard various programmers suggest not including the word "private" in declarations, method signatures, etc. as private is the default scope when not specified. It can make for cleaner code but I'm interested in what the opinions are on whether you use the "private" scope on your variables, methods, etc. Tools like CodeRush that generate code for you include the word "private" so I'm curious if this is good or bad or just a matter of personal preference.
Cleaner code is more explicit as to the designer's intentions. Using private demonstrates a deliberate choice, not open to debate. Falling to the default opens up the questions: was this on purpose, or he simply forgot to include a modifier?
Remove the private and Ask your fellow developers whether they are confused or not
Personally i feel, including private make your code more readable. I would give more importance to "Readability" than "being cleaner"
In a codebase where stuff being public is an information leak (e.g. it will no longer get obfuscated), you want public to stick out. Removing private also has the same 'tide going out' effect on protected and other unnecessarily elevated visibility.
Ideally one'd use a StyleCop rule or similar to make the code actually be consistent (though that, as with all code rules should actually be agreed among the devs before someone comes to a conclusion about it).
(BTW Your contention in the premise re CodeRush's support for omitting it is incorrect - the options allow you to set method visibility etc. to be either private (OOTB) or 'default' (do not specify anything)).
It is up to compiler how to interpret methods or other class members without private, protected or public. It can be changed in nex version. So don't do it.
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 10 years ago.
As proposed by Brandon Walkin (for Xcode, but same thing), more visualization in the IDE can help productivity. In particular, I'd like to provide little icons to better convey the meaning of enum choices or classes (such as UI controls), roughly like this:
The built-in XML comment syntax clearly doesn't support this, but maybe someone has written an add-in to add support for, say, a <img> tag?
Man I love the Visual Studio Gallery for all the good things it contains.
Never seen anything like what you suggest there, but have seen plugin's for adding that kind of content to comments tho. This is one that I can find in there now (http://visualstudiogallery.msdn.microsoft.com/e216ec81-730b-4022-8305-25c39eb1f820), but I distinctly remember that there used to be one that allowed you to link to an image file (an export from say visio or it's ilk), and it would display it inline. I can't find it now tho :-(
You might want to look at this one, which is close, but not quite on the money http://visualstudiogallery.msdn.microsoft.com/c3eaa4fc-f2de-43ad-92ee-f0f257b79005. The source code is available here: http://csharpintellisense.codeplex.com/
And I'd actually like to thank you for drawing my attention back to that fabulous repository of goodness.
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 10 years ago.
I'm starting my 2nd class in C# programming through Kaplan online school. I have some limited interaction with the professor and the class online, but nothing like in an actual school. I'm about to go through "Modern Software Development Using C#.NET" by Richard Wiener. It seems the book as a extremely heavy focus on UML (which I don't even really know what that is right now!)
You experinced Csharpers.... any tips to keep in mind as I go through this to keep in perspective how the modern software engineer works outside the classroom?
Any perspectives to share as I start understanding UML and intermediate C# programming?
Some companies will use UML everywhere. Some use it nowhere. I'm not a big fan myself - I prefer ad-hoc diagrams and plenty of other communication (notes on the diagram, actual talking etc).
The good thing about an ad-hoc approach is that you can leave it as vague as you like or make it really detailed. The bad thing about it is you can't generate any code from it - but I've never really liked generating code from UML. (Others swear by it, mind.)
You certainly don't need to know UML to learn C#.
UML would come very close to the end of the list of things that gave me insight into the complex world of programming. I find it very distracting when trying to design something, and too time consuming for real system descriptions. I have always thought it is important and tried to start my project with UML diagram, but it wasn't ever worth it.
The bigger the projects you are working in the more you need a language to speak with, known by all members of the project team - a common language like UML! But you need not to start learning C# with UML.