8

Fluent API Fluent APIs are generally very useful but one has to be very careful with them as there is a chance of making them overfluent. This means that you try to create an API for every possible combination like: var validator = Validator.For<Person>(ValidationStopConditions.RunAll) .WarnIfTrue(p => p.Age > 50, "Person is older than 50"...


5

I like the idea, but I'm in line with dfhwze meaning it's a little too verbose and complicated to follow, especially when unable to debug. I would prefer a more simple pattern like the one dfhwze suggests: var result = Tester // the person .Validate() .NotNull(p => p.LastName, "LastName is Null") .IsTrue(p => p.FirstName.Length > ...


4

As developer consuming your API .. Usability I find this a verbose way of constructing validation rules. var rules = ValidationRuleCollection .For<Person>() .Add(x => ValidationRule .Require .NotNull(x)) .Add(x => ValidationRule .Require ...


4

This API does feel fluent for consumers to use. You have also included some features I missed in the post you were inspired by. various severity levels [warning, error] custom error messages (although t3chb0t did comment he was working on this) What I'm still missing is a way to throw an exception if I want to. Currently, your API is a sand-box. You could ...


4

Instead of throwing away that list of GovernmentCsvRecord objects after converting it to a StringCsv list, you could keep it around so you don't have to read the csv file again if the IsNumericFile check fails. It looks like you can validate the list of GovernmentCsvRecord objects directly instead of first converting them to StringCsv objects. However, with ...


4

Cleaner consumer interface WarnIfTrue / WarnIfFalse .WarnIfTrue(p => p.Age > 50, "Person is older than 50") .WarnIfFalse(p => p.Age < 50, "Person is older than 50") I don't see a need to create two methods for this. "if true" and "if false" is a matter of thinking like a programmer, instead of thinking like a consumer. You can achieve the same ...


3

Creating an Unique ID Without Loops The problem with incrementing the next ID based on the last cell in a column is you will have to sort the data to ensure that it is in ID order. This really can take away from the user experience. A better approach would be to use the WorksheetFunction.Max() to find the current max ID. "I am very bad at loops" You ...


2

A couple of things that came to me after playing around with this (given one is willing to use the new features of javascript): Making a class for IBAN (ES2015) One could get more fine-grained info using the new named groups on RegExps (ES2018) As an example of the latter: IBAN.formats = { AD: /^(?<bank>\d{4})(?<branch>\d{4})(?<account>...


2

(self-answer) Simplified the API You were right, the API was too verbose so I drastically simplified it. It now presents itself like that: [Fact] public void Simplified() { var rules = ValidationRuleCollection .For<Person>() .Reject(b => b.Null(x => x).Hard()) ....


1

Fight the urge to squeeze multiple "things" into one line. Your script will be easier to read and maintain with all declarations and constructs occupying their own rightful place. Spend the extra lines, you'll be happy you did a year from now. Use curly braces to encapsulate language constructs (e.g. if-else and foreach, etc.), this combined with ...


1

If the parameters are required then they need to be checked and their invalidity must be reported to the caller. There is a HTTP status code for it: 400/BAD REQUEST. The file transfer is done one byte at a time. This is very inefficient. This kind of transer is usually done in 4096 byte blocks. There are libraries for this task too. For example Apache ...


Only top voted, non community-wiki answers of a minimum length are eligible