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.
My recollection from a past employer is that they distinguished between the two as follows:
Validation is the process of checking that the data is appropriate in a very basic sense; for example that data in a date field can be converted to a date, or that characters in a number field can be converted to a number of the appropriate type;
Verification is the process of checking the typed data against some other 'business' rules that you impose on your interface - for example that the Date Of Birth field indicates an applicant within a certain age range.
These memories do not tie in with the Wikipedia article on the subject, nor a BBC BiteSize Revision article.
So what is the consensus: Do people care what methods and processes are called when I am checking Xml inputs for example?
What am I doing when I:
Check that a date field contains characters that are convertible to a C# DateTime;
Check that the DateTime is in an appropriate date range to be stored in SQL Server;
Check that the Date Of Birth indicates a customer over 18 but under 65?
In my vocabulary, validation is checking whether the format of the data is correct, IE if a you're actually dealing with a correctly formatted date string . Verification is checking whether the date you got is actually the date you were expecting.
Ok, so I'll take this as an open invitation to musing...
I think the difference is very much like compile-time vs. runtime errors. Just like the compiler is able to tell that two variables a,b are of type double, and thus the expression a/b is valid, it is only during runtime a DivideByZeroException may be raised if b turns out to be 0.
So to complete the analogy, one can validate that a string looks like a credit card number ('compile time'), but can only verify that it corresponds to a valid card only if one tries to charge the credit card ('runtime') with an amount
Duh. So I guess I understand it pretty much like you old company does.
in terms of programming it makes no difference what you call it (validation or verification) but where you put the logic is important. usually all three rules you mentioned are known to be validations with first two points corresponding to UI validation and last point to business rule validation. we usually validate UI fields using dataannotations in our controller and Business rule validation is performed within business layer. But the bottom line from software point of view is; don't do an operation (save, edit) unless data is good (you call it valid or verified).
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I know that DateTime parsing can be tricky, but since there are a lot of mechanisms are relying on DateTime.Parse() especially its DateTime.Parse(string) overload, I think it makes sense to understand how does it work under the hood and how does it behave on different inputs.
What we know:
MSDN states when you use the DateTime.Parse(String) overload, the formatting is derived from the CurrentThread.Culture, however it draws the attention:
culture-specific data can change (and it did) between the different versions of the framework
the culture-specific data can be overridden by the OS settings
DateTime.Parse() tries to be smart
Because of these it's a bit hard for me to predict what will be result when somebody calls this function on different user inputs.
Even when I specify a culture, DateTime.Parse can recognize strings as valid DateTimes what you might not think to recognize. For example, all the following dates are valid - here are some of my findings:
var at = new System.Globalization.CultureInfo("de-AT", false);
System.Threading.Thread.CurrentThread.CurrentCulture = at;
// it doesn't care about the order:
DateTime.Parse("21.12.2020", at).Dump();
DateTime.Parse("2020.12.31", at).Dump();
// it accepts multiple separators:
DateTime.Parse("2020,12,31", at).Dump();
DateTime.Parse("2020/12/31", at).Dump();
DateTime.Parse("2020 12 31", at).Dump();
// it accepts multiple separators even in a single string:
DateTime.Parse("1999/12-31", at).Dump();
// year must consist at least 3 digits:
DateTime.Parse("100/12-31", at).Dump(); // this works
//DateTime.Parse("99/12-31", at).Dump(); -> this doesn't
DateTime.Parse("001/12-31", at).Dump(); // but this works again (3 digits)
// trimming (well, MSDN mentions this)
DateTime.Parse(" 100/12,31 ", at).Dump();
For me it's not so clear what's going on here. The separators / and , are not even mentioned in the DateTimeFormatInfo.CurrentInfo so I have no idea where did it come from. Are these separators hardcoded in DateTime.Parse? I tried to read the disassembled code, but it was a bit complex for me.
Is there any easy way to summarize what happens and which formats are supported?
I know that in a "real life example" if I have to parse a DateTime with a given format, I should use ParseExact instead, but since there are a lot of stuff relying on this (such as ASP.NET MVC model binding) I think it worths a question what it does exactly - and why does it recognize "100/3.14" as a valid DateTime instead of a division :)
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 9 years ago.
The community reviewed whether to reopen this question 1 year ago and left it closed:
Original close reason(s) were not resolved
I know they are the same variable type, but is there an accepted standard 'style' for whether to use long or Int64?
I would like to use the most common one.
All documentation from Microsoft and 99.999% (or so) of the code you'll find online will use long. See for instance the numeric datatype definition in the C# reference: http://msdn.microsoft.com/en-us/library/exx3b86w.aspx
In the end, this is the same issue with using string or String. In general, lowercase names are used for value datatypes like numbers or characters, and uppercase names are used for classes. In C# Int64 is the complex datatype (a structure with fields, properties and methods, see the doc here) for the long value datatype (see the doc here). In general, people don't use the class Int64 for other than invoking methods from that class, such as Int64.Parse. So you will usually find something like this:
long variable = 9.5f;
string text = "8.4";
long anotherVariable = Int64.Parse(text);
You will get so many different opinions for a question like this since they're the exact same thing. So it's up to you. Microsoft pretty much always uses long, int and short in their documentation and examples. It's simply an Alias in VB.NET and C#. So I guess it's better usage to use them that way.
long instead of Int64
int instead of Int32
short instead of Int16
C# uses these keywords like long, int string, as aliases for .NET-types.
int = System.Int32
long = System.Int64
string = System.String
The first argument to use these keywords is that it comes with the language, so use it when writing the language.
A second argument of using these keywords is that you do not have to put using System; above your codefile.
Another benefit could be that someone could create a new type called Int64 and put it somewhere in your namespace (I know... it would be crazy). If your older code uses the type Int64, your older code could stop functioning. If your older code was using long (an alias for System.Int64) than it would still work fine.
You should use long, int and short.
The one exception I know is in a function name; look at BitConverter.ToInt64.
The reason for that is that long is not defined in CIL while int64 is.
I think it comes down to clarity versus compatibility. Int16, Int32 and Int64 are more clear than short, int and long. You know just by looking at Int16 that it is 16 bits in length.
I think in most cases it will come down to personal preference, but if you are strictly talking "C#" without specifying the underlying platform, I'd think a bit differently. If you are developing to adhere to C# standards for portability across platforms and "future-proofing", "long" would be the best way to go as it is an actual construct in the language itself. "Int64" is an actual struct (System.Int64) in the framework.
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 am trying to write a service in which every user will be assigned a unique name, when he first uses the service. I wish to generate this name, rather than getting the user to set it up. Also, I want the name to be somewhat readable and memorable rather than sound like a GUID or a timestamp. Essentially I want this to be something like the Xbox gamertag.
I know that there will never be more than a 1000 users so maintaining the uniqueness would not be a problem (another reason why I can afford to avoid GUIDs)
I am thinking of taking some adjectives, nouns etc. from the dictionary and generating random but unique combinations of those.
Any suggestions?
You could use a corpus of English language n-grams (say of three letter sequences) and use them to generate words that look like English, but are actually completely gibberish. This kind of data is essentially random, but has a softness for the nature of human language and memory.
This is similar to what I'm talking about, except it combines entire words into sentences probabilistically. I was thinking more of doing it by composing letter sequences into imaginary words.
EDIT actually this page discusses what I'm talking about.
This is just a code example to fully approach your problem. In case it doesn't solve it, please try to be more specific in your question. Pass to the following method an instance of the System.Random class and a list of words (your dictionary).
static string GetGuid(Random random, IList<string> words)
{
const int minGuidSize = 10;
const int maxGuidSize = 15;
var builder = new StringBuilder();
while (builder.Length < minGuidSize)
builder.Append(words[random.Next(words.Count)]);
return builder.ToString(0, Math.Min(builder.Length, maxGuidSize));
}
You can use this list of 10 000 random name:
http://www.opensourcecf.com/1/2009/05/10000-Random-Names-Database.cfm
or use this website to generate a random list of firstname:
http://www.fakenamegenerator.com/order.php
Safe way. maintain the list of remaining non used names.
Easy way (also very scalable) but unsafe. Rely on the unlikelyhood that 2 users randomly get the same id.
I would try to get 3 or 4 lists of about a thousand modalities and then randomly picking one value in each list. That would make about 10E12 possibilities which is enough to avoid collision for 1000 users.
JohnLampMartin2212
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 am updating records. But It gives error
Error converting data type varchar to numeric
Here is the query:
UPDATE tbl_Contract_QutationDetails SET DCont_Discount_Var=23
WHERE DCont_Qty_Code_Var='BLDG/CNQT/11-12/101' AND DCont_Contractor_Code_Var='CNTT1001'
Please give me solution.
I would suggest you first check the column definitions against the data youre passing them and them.
What the error is saying (assuming its triggered by that piece of sql) is that there is some number column youre working with but youre passing the data as a string and that string doesnt represent a number. So,
DCont_Discount_Var=23
Are you sure DCont_Discount is a number? (Seems the answer is yes)
DCont_Qty_Code_Var='BLDG/CNQT/11-12/101'
Are you sure DCont_Qty_Code_Var is a string?
DCont_Contractor_Code_Var='CNTT1001'
Are you sure DCont_Contractor is defined as string?
One of these columns is defines as something numeric, i'd wager
My guess is DCont_Discount_Var=23 should be DCont_Discount_Var='23'
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 looking for a formula interpreter that I can use in a C# application. It needs to be able to interpret a string like this:
max(1+2, 4) * x
I found Writing a fast formula interpreter (codeproject.com) which almost does what I need but it doesn't allow for functions with multiple parameters. I could probably add that functionality to it but I was just wondering if something like this already exists.
Thanks
A couple I've used in the past with no problems:
NCalc
Fast Lightweight Expression Evaluator
You can actually build a very effective interpreter by parsing and replacing certain functional keywords such as max with Math.Max and then dynamically building and executing the formula as a C# class and method. So actually you would be parsing and wrapping the formula and allowing the C# compiler to interpret and execute it.
So, taking your sample formula of max(1+2, 4) * x would turn into:
public class MyFormula
{
public double calc(double x)
{
return Math.Max(1+2, 4) * x;
}
}
Which you would compile on the fly and then execute per the linked article. You still have to parse for and pass the x value of course.
A long time ago in one project i had to create some booking with formulas, and i used VsaEngine. To use this engine you need to add reference to Microsoft.JScript. Here is example:
Code for usage is very simple, just replace formula parameters like:
string formula = "x+y";
formula= formula.Replace("x","100").Replace("y","200");
string result = CalculateFormula(formula);
And here is core method, CalculateFormula:
public string CalculateFormula(string evaluationString)
{
VsaEngine en = VsaEngine.CreateEngine();
Object result = Eval.JScriptEvaluate(evaluationString, en);
return result.ToString();
}
With this you can create your custom formula interpreter engine.