A cool library of constants - best practice?

I used .Net Reflector in the internal application to try to understand what the previous Dev was doing, as well as learn. I have never had actual instructions on how to develop applications, so I take from there (Hooray Stack Overflow). Having said that, I found something that confused me. A class library called WinConstant containing the code below.

Here is my question:

  • What are some possible uses?

  • What is the value when storing a bunch of constants in a library class?

  • Is it considered "Best Practice"?

Thoughts and leadership appreciated!

Public Class clsConstant Public Const cAccess As String = "Access" Public Const cAddress As String = "Address" Public Const cCancel As String = "Cancel" Public Const cCity As String = "City" Public Const cClear As String = "Clear" Public Const cClickOnMessage As String = "Click on any row in top pane to see the detail fields in the bottom pane." Public Const cClientID As String = "ClientID" Public Const cColon As String = ": " Public Const cComma As String = "," Public Const cContactID As String = "ContactID" Public Const cCounty As String = "County" Public Const cDash As String = "-" Public Const cDelete As String = "Delete" Public Const cDepartment As String = "Department" Public Const cError As String = "Error" Public Const cExec As String = "Exec" Public Const cFalse As String = "False" Public Const cFavorite As String = "Favorite" Public Const cFederal As String = "Federal" Public Const cFriday As String = "Friday" Public Const cfrmMain As String = "frmMain" Public Const cfrmModuleLogin As String = "frmModuleLogin" Public Const cfrmModuleSplash As String = "frmModuleSplash" Public Const cHelp As String = "Help" Public Const cHint As String = "Hint" Public Const cImagePath As String = "../../image" Public Const cIn As String = "In" Public Const cInformation As String = "Information" Public Const cInitialScreenID As String = "InitialScreenID" Public Const cInsert As String = "Insert" Public Const cJuvenileID As String = "JuvenileID" Public Const cLetter As String = "Letter" Public Const cManual As String = "Manual" Public Const cMasterID As String = "MasterID" Public Const cModuleID As String = "ModuleID" Public Const cModuleName As String = "ModuleName" Public Const cMonday As String = "Monday" Public Const cName As String = "Name" Public Const cNegative As String = "Negative" _ Public Shared ReadOnly cNLowDate As DateTime = New DateTime(&H851055320574000) _ Public Shared ReadOnly cNullDate As DateTime = New DateTime Public Const cNullDateString As String = "12:00:00 AM" Public Const cOfficeIDDefault As String = "01" Public Const cOne As Integer = 1 Public Const cOut As String = "Out" Public Const cPopUp As String = "PopUp" Public Const cPositive As String = "Positive" Public Const cProcess As String = "Process" Public Const cProviderID As String = "ProviderID" Public Const cQuestion As String = "Question" Public Const cRead As String = "Read" Public Const cReferralID As String = "ReferralID" Public Const cReminder As String = "Reminder" Public Const cReport As String = "Report" Public Const cReportEngine As String = "ReportEngine" Public Const cReportEnginePath As String = "ReportEnginePath" Public Const cReportingServices As String = "ReportingServices" Public Const cReportServer As String = "ReportServer" Public Const cReportService As String = "ReportService" Public Const cReportServiceLocal As String = "ReportServiceLocal" Public Const cReportServiceServer As String = "ReportServiceServer" Public Const cSaturday As String = "Saturday" Public Const cSearch As String = "Search" Public Const cSelect As String = "Select" Public Const cSpace As String = " " Public Const cSQLLoginError As String = "SQL Server login/password invalid" Public Const cStart As String = "Select a module" Public Const cState As String = "State" Public Const cSubjectID As String = "SubjectID" Public Const cSunday As String = "Sunday" Public Const cThursday As String = "Thursday" Public Const cTooltipCancel As String = "Reset form data values back to before all manual changes." Public Const cTooltipClear As String = "Clears all data entry fields prior to an Insert" Public Const cTooltipClient As String = "Display a Client popup window." Public Const cTooltipClose As String = "Close this form" Public Const cTooltipDelete As String = "Delete the current record being displayed, no undo possible." Public Const cTooltipExe As String = "Initiate a batch process." Public Const cTooltipInsert As String = "Insert a brand new record" Public Const cTooltipSearch As String = "Perform a Search for values entered." Public Const cTooltipSelect As String = "Perform a Select for values entered." Public Const cTooltipUpdate As String = "Update an existing record" Public Const cTrue As String = "True" Public Const cTuesday As String = "Tuesday" Public Const cUnderscore As String = "____________________________________________________________" Public Const cUpdate As String = "Update" Public Const cWarning As String = "Warning" Public Const cWeb As String = "Web" Public Const cWednesday As String = "Wednesday" Public Const cWorkerID As String = "WorkerID" Public Const cZero As Integer = 0 Public Shared strLongDate As String() = DateAndTime.Now.ToLongDateString.Split(New Char() { ","c }) Public Shared strModuleMainStatusStripFormID As String = Nothing End Class 
+4
source share
11 answers

In the days of coding windowed applications, c had similar # files included in windows consisting of long lists of #defines creating constants. Various c applications simulated this approach in their own files. The "class" seems to be the "transliteration" of this "c-ism". The fundamental principle of object-oriented design is to mix code and data with the corresponding functional units: objects. As jfullerton wrote:

From a programming point of view, object orientation includes program objects, encapsulation, inheritance, and polymorphism. Conceptual objects are modeled in program code. Encapsulation stores object data and methods that use data together as part of an object.

It is so clear that this list of constants does not correspond to OO methods, but this is a return to the old days.

To answer your questions:

  • - This class contains constants, i.e.
  • - Perhaps the old developer did it because it was what he used to do
  • “These are not real best practices.”

Naturally, if this is part of your application, you cannot just throw it away. Rather, it is something that needs to be reorganized over time, assuming you are using the current best practices of Test Driven Development and Refactoring.

+8
source

Separating literals from the rest of the code is a good idea.

What is strange is that these are mainly resources, not constant lines. Then they can be easily localized if necessary or replaced / updated without recompiling the entire application.

Some of these shoudln't even be resources: cUnderscore , for example, looks like this, using text to create a visual effect is usually a bad idea.

In your defense of the predecessor, I believe that this code is preferable to find the same constants scattered throughout the source, as it will make refactoring resources a little easier.

+7
source

A constant is something that never changes, for example

 Public Const NumberOne as Int = 1 

So this is my first point: some of the things you summed up are not really constants.

Another disadvantage is that using the const keyword creates a binary dependency. This means that you will have to rebuild the assembly that uses your .dll constant file. You cannot just replace it. This is due to how constants work: the compiler replaces the name with a value at compile time .

The solution to this problem is to use ReadOnly instead of Const.

I really don't think it is good practice to create such a library. I would not allow my team to create anyway ...

+4
source

It seems that the developer had a coding standard that states: "Do not use string literals in your code and dutifully separate each constant, regardless of whether it makes sense or not.

For example, there is probably some element where the code requires the number 1, and instead of using DefaultNumberOfLineItems or some other descriptive constant, they used NumberOne = 1;

Best practice would be to keep constants descriptive and close to their point of use. There is nothing wrong with a static class of related constants that have some type of value and are related to each other.

For example, there is a system in which I worked with tag attributes with unique keys. These keys are collected in a static class with descriptive attribute names; in fact, the keys are generated by an automated system

 public static class AttributeIDs { public const string Name = "UniqueGeneratedKeyForNameAttribute"; public const string Description ="UnqiueGeneratedKeyForDescriptionAttribute"; ... etc. } 

In practice, it is used as

 MyAccess.GetValueForAttribute(AttributeIDs.Name); 

which unites all related constants.

+4
source

There are possible useful scenarios for this class. Typically, things like “magic number” or “magic strings” are included in constants and placed in a static (general) class. The reason for this is to isolate these "magic" values ​​in one place and allow them to refer to a meaningful name. (Usually used for numeric values.) In the case of string values, this helps ensure that things are referenced the same value each time. The best example of this is the string keys in the app.config file.

In this case, the constants should be used for something that does not change (or rarely changes, that it is effectively constant). For the most part, strings that can change (or need to be localized) should be stored as resources in a .resx file.

+2
source

There is nothing wrong with having a class library of constants. Constants are good practice overall. After all, everyone is listed in .NET, and they are simply grouped by numeric constants. Having a dependency on a const assembly is no different from any other dependency. Understanding the purpose of constants is more related to application logic. I assume that these constants allow you to maintain a verbose log without populating the application with a bunch of string literals.

+2
source

It really looks like a naive row table implementation.

Values ​​are not magic strings and "easy" system-wide changes. I would say that a resource file is easier to implement and maintain.

Is your colleague the best practice? I would say no. Using string tables, this is especially important if you need internationalization in your application.

+2
source

Including string constants in a separate class is best practice in many situations, but this is a bad example. The best way would be to create a StringConstants namespace and then organize the strings so that the related string constants are organized into separate classes. This is just a poor implementation of a good idea.

If globalization is a concern, then (as others have pointed out), strings should be stored in resource files.

+1
source

We do this to extract specific database constants from the database. This decoupling allows us in the future to upgrade the database (currently MS Access) to something better (probably SQL Server) without changing a very large part of the code base at all. Here is an example of a table with a specific block of constants:

  Public Class Equalisations Public Const TableName As String = "Equalisations" Public Class SPs Public Const SelectAll As String = General.SPs.Prefix & TableName & General.SPs.SelectAll Public Const SelectDropDownList As String = General.SPs.Prefix & TableName & General.SPs.SelectDropDownList Public Const SelectAllChildRecords As String = General.SPs.Prefix & TableName & General.SPs.SelectAllChildRecords Public Const SelectRecord As String = General.SPs.Prefix & TableName & General.SPs.SelectRecord Public Const SelectMaxId As String = General.SPs.Prefix & TableName & General.SPs.SelectMaxId Public Const InsertRecord As String = General.SPs.Prefix & TableName & General.SPs.InsertRecord Public Const DeleteAllRecords As String = General.SPs.Prefix & TableName & "_DeleteAllRecords" End Class Public Class Cols Public Const CompanyAccountID As String = "CitiAccountID" Public Const NAVDate As String = "NAVDate" Public Const GLCodeID As String = "GLCodeID" Public Const Income As String = "Income" Public Const LoadedFileID As String = "LoadedFileID" End Class Public Class Parms Public Const CompanyAccountID As String = "pCitiAccountID" Public Const NAVDate As String = "pNAVDate" Public Const GLCodeID As String = "pGLCodeID" Public Const Income As String = "pIncome" Public Const LoadedFileID As String = "pLoadedFileID" End Class End Class 
+1
source

The only explanation I can think of is some message library, but this does not apply to 90% of the entries.

For example, this is just stupid:

  Public Const cInsert As String = "Insert" 

It smells really bad.

0
source

There are two types of constants available in C #: compile-time constants and run-time constants. They have different behaviors and using the wrong one will cost you performance or correctness. therefore, select the correct constant type that you use for your project.

http://dotnetacademy.blogspot.com/2011/09/constants-in-net.html

0
source

All Articles