Ahh, C# structs: a classic carryover from the C/C++ days. Have you ever used one? Wondering how they work? Well, they are similar to classes with some substantial differences. Structs have niche value to us as C# developers. You don’t often need them, but there are some things they do better than classes.
They also come with some caveats. Let me walk you through all this through a series of code examples.
Why do we need code comments? I would not be surprised if your first answer is, “We don’t.”
I get it. Senior developer after senior developer has taught us that “comments are bad.” And we cheerfully nod our heads, saying, “I am smarter for not using them.” We grin smugly when we see one of our juniors make the “mistake” of using comments in their code.
But as much as we sometimes abuse them, we still need comments.
I know comments don’t affect the code’s behavior. I understand how they can get stale and stop making sense. I am all for writing clean code, and I do my best to ensure my variables, methods, and class names describe their intent as accurately as possible. If I see dead code lying around in the comments for a while, I delete it.
But here is the bottom line: we need code comments because there are some things they do better than plain code. Here’s why.
Time for yet another deep dive into three more CodeIt.Right Rules. For those of you who don’t know about our CodeIt.Right Rules series, here’s a brief explanation.
CodeIt.Right is one of the tools offered by SubMain. It’s a static code analyzer tool or, more specifically, an automated code review tool. CodeIt.Right works by checking your code against a set of rules and giving you instant feedback on how to solve potential problems. It even offers automatic fixes when applicable.
In each installment on this ongoing series, we explain three CodeIt.Right rules, usually picked from as diverse a category?as possible, to showcase the flexibility and breadth of the ruleset.
Readers of this series know that we like to start these posts by stating two things:
Yeah, you could simplify this down to ?always understand a suggested fix.??But I choose to not put it that way since I want you to really think and consider your options. If you decide to ignore a fix, do so understanding the consequences. On the other hand, if you accept a suggested fix, do it with a full understanding of how that’s going to benefit your application.
With all that in mind, let’s get to today’s rules.
It seems easy for people to say things like “LOL, Web Forms” or “Web Forms is dead.”?Web Forms sometimes?gets very little respect from the .NET development community. We look forward in time, forgetting the giants on whose shoulders we stand. It was the?dominant way of making websites in .NET for many years. Is it really a remnant of a bygone era? Or does it have a vibrant existence in places oft overlooked?
We as software developers have created several disciplines for coding: test-driven developments, clean code principles, and screaming architecture, to name a few.?However, we often find our web.config files can sprawl out of control.
We just don’t pay as much attention to our configuration as we do to our?classes and methods. The good news is that many mistakes are easily avoided, and with a little discipline we can put our configs on par with the rest of our codebase.
In this post, I’ll show you how. We’ll look at five of the most common configuration mistakes and how to avoid them.
Download a free trial of CodeIt.Right and get an instant, automated code review.
You’re checking out some code. It’s been a long time since you looked at this project. Or maybe it’s the first time. You point your editor at an interesting file name and double-click to open it. Your coffee is warm, your mind is clear, and you’re ready to go.
And there it is, sticking out like white socks in sandals. A spelling error.
How do you handle it? Do you fix it? Do you ignore it? Discuss it with the author? Bring it up during lunch when he’s not around?
Note to the GhostDoc v5 users: The v2018 requires a new license code. Users with License Protection or active Software Assurance subscription are eligible for a free upgrade. See the information at the bottom of this post for the details.
The v2018 release is packed with new and exciting features of which one particular is long awaited for – visual editing for XML comments – the?feature that makes XML documentation authoring a breeze!
<inheritdoc /> tag – in the XML Comments as well as the generated help documentationFor the detailed list of v2018 changes see What’s New in GhostDoc v2018
To see new features by product edition see this page ? http://submain.com/ghostdoc/editions/
The number one challenge authoring XML comments, according to our users, has been ensuring a well-formed XML that includes encoding HTML formatting tags, code samples, etc. If that is not painful enough, many of malformed XML issues don’t even show up until the help docs are generated.
And now we offer a solution to this! Visual editing makes it painless to insert tables, lists, pictures, links, source code samples, and other formatting directly in your XML doc comments.
This is a huge leap from plain XML comment maintenance. Now you have WYSIWYG editing and don’t have to worry about valid and compliant XML in your comments. And there is no longer need to look up the correct syntax of the XML comment section tags and format to use.
The visual comment editor allows you to create and edit comments directly within an editable preview of the generated documentation. Comments created with the visual editor are written back to your source code in standard XML format, properly encoded, when required.
You still can have GhostDoc auto-generate your XML doc template in the Visual Editor, and then you have a Word-like experience to continue editing your documentation.
The new Visual Editor is such a great improvement – we also included it with the GhostDoc Community Edition!
We have updated the web documentation themes with a modern frameless design. The new themes also allow for the help documentation search locally not requiring the server side active component. The older frame-based themes are still included for compatibility with the new names.
Instead of copying and syncing the base member XML Comment summary for a type member, using?the <inheritdoc /> tag allows GhostDoc copying the documentation from base members into the final help documentation at the time the documentation is generated hence always rendering the latest copy of the base member docs.
GhostDoc now will take your Code Contract XML Comment details and render them in the generated help documentation and Visual Editor. GhostDoc supports the following Code Contracts XML elements
<ensures /><ensuresOnThrow /><requires /><invariant /><pure />To create the XML Comment tags for Code Contracts, we recommend using the?CodeContracts tools for .NET
We added a new documentation output format – the IntelliSense file which is similar to that Visual Studio produces and GhostDoc users can also leverage of all the filtering built-in into the Build Help Documentation dialog as well as can generate it via the command line tool.
The VS IntelliSense format takes place of the MS Help 2 documentation output format that GhostDoc no longer supports.
We must never say never – now GhostDoc has a new command to generate XML Comment templates for a whole project – Document Project.
Creating a file header used to be part of the Document File batch command and while it still is, we introduced the Document File Header command that allows generating and updating file header without having to re-document the whole file.
Using regular expressions can enable developers to do simple yet powerful things. Now you can use regular expressions in the Summary Override dictionary to improve the quality of the generated comment templates.
Here are two sample Summary Override entries:
New(?<pattern>(.|\n)*) -?Creates new {pattern}.
To(?<pattern>(.|\n)*) -?Converts to {pattern}.
These will create summary for NewCustomer as “Creates new Customer” and for ToModel as “Converts to Model”.
Download the v2018 at http://submain.com/download/ghostdoc/
Let us know what you think of the new version here ? http://submain.com/support/feedback/
Note to the GhostDoc v5 users: The v5.x license codes won’t work with the v2018. For users with License Protection and active Software Assurance subscription we have sent out the v2018 license codes. If you have not received or misplaced your new license, you can retrieve it on the My Account page. Users without the License Protection or with expired Software Assurance subscription will need to purchase the new version – currently we are not offering upgrade path other than the Software Assurance subscription. For information about the upgrade protection see our Software Assurance and Support – Renewal / Reinstatement Terms
Time to cover yet another construct of the C# language. In this series, we’ve already covered the C# list, array, and string, to name a few. Today’s post is a little bit different, though. Its subject isn’t a data structure or type, but instead, a decision structure: the C# switch statement.
In this post you’ll learn all about the switch statement. What is it, how should you use it, and when should be careful using it?
Le’s get started!
We here on the SubMain blog love to talk about programming best practices.?Sometimes we’ll cover topics that are specific to C# or .NET as a whole. Other times, however, we write about concepts that are universal. Today’s post falls into the latter category. And I’ll start out by making a strong claim: you absolutely should treat warnings as errors when developing in .NET. Well, to be honest, that applies to virtually any platform.
The examples in this post, as usual, will be in the C# language.?But as we’ve said, the concept applies pretty much everywhere.
Code review is, hands down, one of the most fundamental best practices a software shop can employ to produce better software. A good code review practice can shed light on design problems, improve the readability of the code, and spread knowledge throughout a team. It also helps you find bugs early (when it costs less to fix them).
Code reviews sound like a gift from the heavens, right? While far from being a panacea, I’d say they are a spectacular tool to ensure software quality?when done correctly. And that, of course, is the tricky part. It doesn’t take much for a code review practice to go downhill. If you’ve been a developer for at least a few years, then I’d bet you have your share of scary stories to tell.
But that’s not what we’re here to talk about today. Forget the truly horrific stories?toxic workplaces and the like. Today we’re going to cover inefficiency in code reviews. Or, more precisely, we’ll offer you tips on how you can avoid it.
So, without further ado, let’s get to it: four tips that will help you when preparing to implement a code review practice in your software shop.