My principles for developer software in .NET

07 Jul 2019, CSHARP

972 Palavras, por José luiz

#Rules , #Conventions , #Environment



Intro

Hello Developers, how it’s going? So, today I’ll share with you my personal rules to software development, but I won’t speak about SOLID or ACID this will be to another post.

What I want to share is some rules, or maybe principles that I really believe when I go to make a software especially using .Net Stack

I strongly believe that you should follow it all of them.

Those principles I made after 9 years of software development and review codes. I know! this can be personal, however It’s valid to share…


My Principals

Ahhh the principals aren’t prioritized, just numbered

  1. Conventions Names
  2. Avoid Regions
  3. Use Exception to handle Erros
  4. Void boolean parameters
  5. Try to avoid many parameters
  6. Warning as Rrros
  7. Encapsulate Complex Expression
  8. Try to Avoid Multiple Exists
  9. Keep your methods short
  10. Keep yuor Classes short
  11. Prefer Interfaces instead of Abstract Class

#1 Conventions Names


It seems obvious, but I see “strEdit” or “edt_name” on components or field names … Old developers always argue about nomenclature for variable names, classes, methods … In my opinion, just follow this Guidelines all of design-guideline are there done to use.

It’s just:


I don’t really like!

  1. Name fields with initials that reference the type (strName, str_name)
  2. Name elements with element type (edtName)
  3. Variables with nonsense name
  4. Classes with nonsense names
  5. Lack of pattern! If you start with “str” for example, for some policy, do it to the end!

#2 Avoid Regions


Are your crazy, Jose? Regions are used to facilitate navigation in a large class, and there is the problem! If a class is large enough to have to organize with regions maybe the problem is in your code.

If you have a class where you need to use regions to organize it… maybe a little OOP will solve

The tru is: Regions exists to hide codes, period.

   class Customer
   {
      #region CustomerManager
      ...
      #endregion
      #region CustomerRole
      ...
      #endregion
      #region CustomerAccess
      ...
      #endregion
      #region CustomerMethods
      ...
      #endregion
   }

#3 Use Exception to handle Erros


In Boolean methods, use Exceptions for handle erros, this lets you extend and understand what is really happening. There are certain times that the flow is more indicated, Exception should be used to indicate an error in the program.

In the code below the error would probably be in the call by allowing name null, but the fact is that the method returns false and should in fact be an Argument Exception.

   public bool CheckCustomer(string name)
   {
       if (string.IsNullOrEmpty(name))
       {
         return false; 
       }
       ...
       return true;
   }

#4 Void boolean parameters


Avoid Boolean parameters, You can overloaded methods for this purpose, or even use interfaces to change behaviour of methods,but using boolean parameters isn’t a good deal, you never ever know what the parameter was actually created,

see the example: What does the parameter do? Close the connection? Close the file?

   storage.Write(data, false);

You will know after going to the method.

   public void Write(string file, bool flush)
   {
       // ...
       
   }

You should create another method to handle it, see the access modifier.

   public void WriteAndFlush(string file)
   {
       Write(file, true)
       
   }

   public void Write(string file)
   {
       Write(file, false)
       
   }


   private void Write(string file, bool flush)
   {
       // ...
       
   }

#5 Avoid many parameters


Many parameters in method make me think “What is the relationship between them?” I like to see 3 maybe 4 parameters, use a class to handle this.

Avoid:

   public void Login(string username, string password, bool persist, string ipAddress, IUser user, IUserServices services)
   {
       // ... 
       
   }

What could be done:

   public void Login(ILoginUser user)
   {
       // ... 
       
   }

#6 Warning as Erros

Configure your BUILD to a treated warning as error. Remember Warnings will make your code bad and difficult to test!

If you are using Visual Studio, open your configuration and change the BUILD config if your are using Visual Studio Code just open the file .csproj and add the tags:

  <PropertyGroup>
    <TreatWarningsAsErrors>true</TreatWarningsAsErrors>
  </PropertyGroup>

Done, now your warnings will be treat as Erros…

#7 Encapsulate Complex Expression:

If you have a complex expression just make sure that could be a Method!

Avoid:

  
   if(login.Try > totalAllow && !login.IsVip && login.DueDate > CurrentDate)
   {
     // ..
   }

What could be done:

   if(login.IsAllowToAccess)
   {
     // ..
   }

#8 Try to Avoid Multiple Exists

In Boolean Method try to avoid multiple exists - directly.

Avoid:

  
   if(Account > 0)
   {
     return false;
   }
   else if (IsVip)
   {
     return false;
   }
   else if (Account < 10)
   {
     return false;

   }
   else if (PastDue)
   {
     return false;

   }

   return true;

Is better:

   bool isValid;
  
   if(Account > 0)
   {
     isValid = false;
   }
   else if (IsVip)
   {
     isValid = false;
   }
   else if (Account < 10)
   {
     isValid = false;

   }
   else if (PastDue)
   {
     isValid = false;

   }

   return tisValid;

#9 Keep your methods short

Developer, this is required, keep your methods short! If you need, just create another Method with suggestive name and also avoid comments.

#10 Keep your Classes short

Another important point here, keep your classes short, Use abstract, interfaces, Delegates.. Yeah! I know the core point here is “How small is enought?”

Short to someone else can understand easily your code.

#11 Prefer Interfaces instead of Abstract Class

I know it will depend on the project, what I mean here is the fact that many developers abuse to much of abstract classes that the code is unreadable and not functional, remember that C# does not accept multiple inheritance classes right? Thus use Interfaces, they are cool.

Finally

Building software does not only mean focusing on the delivery the project but rather on taking care about the code and how it will be maintained and grow, believe me!

I’m tired of picking projects up or re-writing projects because of poor code creation, I know why I’ve been like this!

Make sense to you?

Let’s practice good inside codes, beauty?

Note...

Hy, I'm José Luiz and my commitment is to no bullshit post, no sponsored posts, no ads, and no paywalls.

If you enjoy my content, please consider supporting what I do.

Support my work and save the World!

All support is send to MSF & O Bem nunca para :)