SubMain.com
YouTube
RSS

CodeIt.Right

Home Category: CodeIt.Right (Page 4)
C# Logo with Lock

Quick Tips for Better C# Security

Justin Boyer4 Comments

Application security is a hot topic. No one wants to write code that leads to the next data breach or major headline. C# security is on the minds of many .NET developers.

Secure coding involves detailed knowledge of a programming language and framework. There could be dozens of rules articulated here with detailed code examples showing right versus wrong coding practices. However, that might lead to quite a bit of dry reading and low retention. Instead, I’ll take a different angle. I’ll describe three principles that lead to strong, secure coding practices. Learn these principles well, and you’ll be able to secure any application you build.

(more…)

CodeIt.Right Rules Explained 13 includes

CodeIt.Right Rules Explained, Part 13

Erik Dietrich1 Comment

It’s time for another post in the CodeIt.Right Rules Explained series.? If this is the first such post you’ve seen, I’ll explain briefly how it works.? CodeIt.Right is an automated code review tool for .NET, and it has a bunch of rules.? In these posts, I explain those rules in detail.

Whenever I post in this series, I start with my two rules of thumb for static analysis.

  • Never implement a suggested fix without knowing what makes it a fix.
  • Never ignore a suggested fix without understanding what makes it a fix.

As always, I’ll explain that I don’t phrase it this way to be cute.? You could reduce this logically to “figure out why the tool is suggesting this.”? But I specifically opt not to.

The reason is that each time the tool confronts you with a warning, you have a choice: address the warning or ignore it.? And in either case, you should make that choice for the right reasons.? Are you ignoring it because you’ve determined that the pros of having it outweigh the cons the tool is warning you about?? Or are you ignoring it because you don’t feel like dealing with it?? The same thing applies, too, on the side of implementing fixes.

So, that said, let’s dive into three more rules today.

(more…)

4 Common Datetime Mistakes in C# And How to Avoid Them

Carlos Schults12 Comments

Do you remember the “falsehoods programmers believe about X” meme that became popular among software blogs a few years ago? The first one was about names, but several others soon followed, covering topics such as addresses, geography, and online shopping.

My favorite was the one about time. I hadn’t thought deeply about time and its intricacies up until that point, and I was intrigued by how a fundamental domain could be such a fertile ground for misunderstandings.

C# Datetime Stamps

Now even though I like the post, I have a problem with it: it lists wrong assumptions, and then it basically stops there. The reader is likely to leave the article wondering

  • Why are these assumptions falsehoods?
  • How likely is it that I’ll get in trouble due to one of these assumptions?
  • What’s the proper way of dealing with these issues?

The article is interesting food for thought, but I think it’d make sense to provide more actionable information.

That’s what today’s post is about. I’m going to show you four common mistakes C#/.NET developers make when dealing with time. And that’s not all. I’ll also show what you should do to avoid them and make your code safer and easier to reason about.
(more…)

Code review vs pair programming (as shown here): which should your team pick?

Code Review vs Pair-Programming: Which One Should Your Team Pick?

Carlos Schults3 Comments

Some weeks ago, I was browsing Twitter when I saw this:

This prompted a brief discussion between the author and me. He made good arguments, but I left unconvinced that pair programming was the obvious winner.

As someone who?s implemented code review with success and also paired to some extent, I could see how both practices can be valuable.?But is one of them clearly better than the other? Are code review and pair programming interchangeable, or are there scenarios in which one clearly shines?

That?s what I?m going to answer today. Let?s dive in.

(more…)

Released: CodeIt.Right v3.2

Serge BaranovskyNo Comments

A new CodeIt.Right?update is available now – version v3.2 – includes VS2017 performance improvements, minor enhancements, and bug fixes:

  • Resolved: Improved performance loading solutions in VS2017 by moving it to an async thread
  • Resolved: Code quality hints now showing up correctly in VS2010-2015 Editor
  • Resolved: DoNotCatchSpecifiedExceptionTypes rule in VB now works correctly when the Catch clause has a When section
  • Resolved: Exception when “Analyze checked out files” is ON and a source file renamed or removed from disk
  • Resolved: AsyncMethodShouldHaveAwaitStatement rule no longer shows a violation when the await statement is on right side of assignment
  • Resolved: Now don?t run new version check when in Debug mode
  • Added: Support for StyleCop VSIX v5.0

For the complete and detailed list of the v3.2 changes see What’s New in CodeIt.Right v3.0

How do I try it?

Download the v3.0 at http://submain.com/download/codeit.right/

Feedback is what keeps us going!

Let us know what you think of the new version here – http://submain.com/support/feedback/

 

CodeIt.Right Rules Explained, Part 12

CodeIt.Right Rules Explained, Part 12

Erik Dietrich1 Comment

This week, we bring you another post in the CodeIt.Right Rules Explained series.? In case this is new for you, with each post in the series, I take you through three CodeIt.Right?rules in detail.? CodeIt.Right is an automated code review tool, making use of static code analysis.

As I always do with these posts, I’ll start with two solid rules of thumb for static analysis.

  • Never implement a suggested fix without knowing what makes it a fix.
  • Never ignore a suggested fix without understanding what makes it a fix.

And, as I always do, I’ll explain that I don’t phrase it this way to play some sort of game.? You might wonder why I don’t just tell you to learn every suggested fix and call it a day.

Well, I phrase it this way to make it clear that you face a specific choice each and every time you encounter an analysis warning: fix it or ignore it.? And when you make that choice, you should make it for the right reasons.? “I don’t know what this means,” isn’t the right reason.? I also approach it this way because trying to learn?all?of the rules at once would prove extremely daunting.

So let’s dive deep into understanding another three rules today.

(more…)

An entire large team arguing over the coding standard.

What’s Your Worst Experience with a Coding Standard?

Erik Dietrich9 Comments

I remember the first time I encountered GhostDoc.? It was an oasis in a professional desert of soul-sucking conformity.

Okay, wait. Let me back up and explain.

I was working in a custom app dev shop at the time.? While working there, I worked on an assortment of apps, big and small, and I delivered to an assortment?of clients, big and small.? Some had their own internal maintenance devs, and some did not.? And yet, in spite of this disjoint, hodgepodge arrangement, the company maintained a single?and relatively?involved coding standard for dozens of folks on dozens of projects.

The “Professional” Coding Standard

Most aspects of the standard were unremarkable and understandable.? So, on the whole, this didn’t bother me.? But there was an edict floating around in there that said every method and class, no matter what, needed XML doc comments.

This applied to code being maintained by client developers and to code that nobody would ever look at again.? It applied to both API deliverables and to GUI crud apps that nobody would touch again.? Why comment everything in this fashion, no matter what?? Because it makes us “look professional,” that’s why.

Ugh.

And so I found myself laboriously going back and brainlessly adding comments to dozens of files.? You see, I hadn’t known about this standard when I started, so I didn’t bother commenting this forms-over-data thing for which we weren’t even delivering source code.? So I had a lot of “work” to do.

Initially, I contemplated writing my own commenting engine.? I honestly think I could have done that in less time than it would take to hand comment.? But then I figured something like this had to exist already, and my search led me quickly to GhostDoc.

Once I discovered that, I sprayed my code with comments like an exterminator taking care of an ant problem.? Then I called it a day.

As I’ve discussed previously, this is NOT how I’d use GhostDoc today or how I’d approach commenting in general.? But it got the “job” done, and the powers that be considered “my” comments completely acceptable.? Project finished.

(more…)

CodeIt.Right Rules Explained, Part 11

Erik DietrichNo Comments

It’s time for another post in the CodeIt.Right Rules Explained series.? I daresay it’s becoming a pretty predictable post series, with a pretty predictable cadence.? And that’s a good thing!? CodeIt.Right offers automated code review, and this series of blog posts gives you a detailed tour of the what and also the why of the code review rules.

As has become custom, I’ll start with two solid rules of thumb for static analysis.

  • Never implement a suggested fix without knowing what makes it a fix.
  • Never ignore a suggested fix without understanding what makes it a fix.

Every month, I explain that I don’t phrase it this way to play some sort of game.? After all, I could just declare that everyone should learn every suggested rule and be done with it.? But I phrase it this way to make it clear that you face a specific choice each and every time you encounter an analysis warning: fix it or ignore it.? And when you make that choice, you should make it for the right reasons.? “I don’t know what this means,” isn’t the right reason.

So let’s dive deep into understanding another three rules today.

(more…)

You don't need a code review template like the one shown here.

You Don?t Need a Code Review Template

Erik Dietrich1 Comment

What do you have in mind when you search or hope for a code review template?? I’ll bet I can guess.

You’re looking for something to guide you through the process.? In your mind, this probably takes the form of a worksheet of some kind.? The appropriate document should have a checklist of items for you to tick off and perhaps some free-form text spaces for you to make notes.? It will also guide you through the process in general.

I get it.? But you really don’t need this, even though it seems perfectly reasonable and inviting.

The Actual Life of a Code Review Template

Before I dive into the meat of?why you don’t need this document, let me talk about what will happen to it when you acquire it.

First, you’ll go searching and find something like this.? Then you’ll find a few more of those and put it together into your own list.? It will include items like the following:

  • Each method should have a clear responsibility.
  • Each method should also have no more than three parameters.
  • Close any connections you open and dispose of any resources that need disposing.

And so on.

You’ll put this document together, and then you’ll stick it on your group’s SharePoint site, where everyone can see it and add to it if need be.? “It’s a living document,” you’ll assure everyone.

Your brand-new code review process will get off to a good start, with people participating and faithfully following the code review template.? They’ll check the checkboxes, fill out the text for the questions, and generate adjustments to the code where needed.? For a while, anyway.

But where you’d eventually expect the efficiency of these reviews to improve, the opposite happens.? The document grows. Code reviews get longer and more mind-numbing, and people start to hate them.? Then, they start to?avoid them altogether, when possible.? The group’s collective dissatisfaction eventually leads to an overhaul of the process.

And the code review template sits there on SharePoint, untouched, like a digital fossil.

(more…)

CodeIt.Right Rules Explained, Part 10

CodeIt.Right Rules Explained, Part 10

Erik Dietrich1 Comment

Like any good habit, I’ve settled into a cadence with the CodeIt.Right Rules Explained posts.? They’re coming about once per month or so, and each one offers a deep dive into three of CodeIt.Right’s?rules.? As always, I’ll start by citing my two personal rules about static analysis, along with a brief explanation.

  • Never implement a suggested fix without knowing what makes it a fix.
  • Never ignore a suggested fix without understanding what makes it a fix.

This isn’t a rhetorical game.? I could condense the statements and say ?learn the reasoning behind all suggested fixes.? ?But I say it the way that I do to call your attention to a decision that you face when it comes to static analysis warnings. ?Every time you encounter a warning, you must either choose to ignore the feedback or to address it. ?And regardless of which you chose, you should really understand the logic behind the suggestion. ?Otherwise, how can you possibly make the right call?

In that spirit, I?m going to offer up explanations for yet another three?CodeIt.Right?rules today.

(more…)

Menu