Tag Info

New answers tagged

2

In the early days of .NET and my endeavors into .NET land I used the same mechanism, i.e. to signal callers that the collection / container object they passed to the method was changed inside the method. But after a while I realized what is better worded in Dan Ling's answer above, namely that this is actually wrong: ref has a different meaning, and it ...


5

Understand that the ref keyword signifies an intent to reassign the pointer. If you enable Microsoft's code analysis, you will get a warning telling you that using ref param is likely a bad design. Passing by ref is not just a 'visual' or syntactic sugar change. It actually allows the method to reassign the reference to a new object, which affects the ...


4

Ugh. Always impressive when humanity shows how creatively terrible it can be... Yes, the proper approach here is to return an IEnumerable of whatever your error type is (unless you're just using exceptions, in which case AggregateException exists). If you're doing anything remotely fancy with the errors, a special object that has a pass/fail property and is ...


0

As everyone else has said, no, that's not valid syntax. I'd suggest writing a between() function, so you can call between(0, a, 22.4). If you're working in a OO language, you could add a between() method to your Heading (or whatever) class, which then gives you a natural-reading if(a.between(0, 22.4)) idiom.


0

You cannot express intervals like this: 22.5 <= a <= 44.9 "(a is between 22.5 and 44.9)" You have to break it up into two expressions, and 'and' them together: 22.5 <= a && a <= 44.9 (22.5 is less than or equal to a and a is less than or equal to 44.9).


3

No. You can't just "invent" syntax. Think about what the compiler has to translate this into: if( 0 <= a <= 22.4 ) First test whether [the integer] 0 is less than or equal to the variable a : this yields a Boolean result. Then try to test whether this [Boolean] result is less than or equal to [the integer] 22.4. Comparing Booleans and integers? ...


4

There are a few languages that let you specify conditionals like that, but most popular languages require two separate comparisons joined with an &&, like: if (0 <= a && a <= 22.4) However, there are easier ways if you have a long list like this. For one thing, if you have a value like 22.45 it won't hit any conditionals. For ...


0

No, (really dependent on language) your conditionals should be variable operator value. So: x > 3 and x < 5 is valid but 5 < x < 3 is not. You can use parenthesis to achieve the effect: (x < 5 and x > 3) and x >= 4 is valid, however your should really consider restructuring. if (x > 3 and x < 5) do some stuff if (x ...


2

There is no perfect answer. The best compromise I've found: if ( condition ) { ... } else { // Otherwise ... } This might make a little better sense in fuller context: // Comment about what this next section does if ( condition ) { // Comment about the then clause ... } else { // Comment about the else clause ... } For ...


1

This seems like the sort of situation where XML would work well. You can start with basic tags for things like being required, or being a given length, etc; and if later you get new requirements that need a new kind of constraint, you just add a tag and code to check for that tag.


1

Most languages have some sort of validation library available to you. In C#, for example, I've used FluentValidation, which allows you to specify your business rules with a fluent API. public class Post { public string Title; public string Body; public DateTime CreatedAt; } And the validator: public class PostValidator : ...


0

I used a utility program many years ago which did a similar thing. Given a flat file, it could parse each record and check each column met certain requirements. The basic blocks were types, ranges and values. Types were very basic ones such as: String Int Float Date For some of these columns, ranges could be defined. For example, you could say that for ...


2

My experience is that it isn't worth spending too much time on perfecting a syntax for expressing requirements. The requirements will change again, and very probably in ways that you didn't anticipate, so it's unlikely that you will hit on the perfect solution in any reasonable time frame. It is usually easier to just keep around the old parsing code as a ...



Top 50 recent answers are included