We Keep Coding

c# string.CompareOrdinal vs operator == [closed]

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 5 years ago.
Improve this question
I want to compare two strings in a linq expression. Do I take advantage if I use `string.CompareOrdinal or is it the same?
list.Where(str1 => string.CompareOrdinal(str1, str2) == 0);
list.Where(str1 => str1 == str2);

According to benchmarks done by someone else, string.CompareOrdinal can be slightly faster than == when doing a lot of comparisons:
Most of the board remained green up through 10,000 comparisons and didn’t register any time.
At the 100,000 and 1,000,000 marks, things started to get a bit more interesting in terms of time differences.
String.CompareOrdinal was the constant superstar. What surprised me is for the case-insensitive comparisons, String.CompareOrdinal outperformed most other methods by a whole decimal place.
For case sensitive comparisons, most programmers can probably stick with the “==” operator.
-- The Curious Consultant: Fastest Way to Compare Strings in C# .Net
Note, though, that we are talking about a total difference of 3 milliseconds for 100,000 case-sensitive string comparisons, and that no measurable differences have been observed for 10,000 and 1,000,000 comparisons.
Thus, is very unlikely that this difference is relevant to your application (especially if you are using LINQ-to-objects), so the more readable == should be preferred.

Rule of thumb about when to use a temp object to hold reference to an object, rather than referering the whole path at every use? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I guess this question is for a large part a matter of what you prefer aswell as being very situational, but I just came across a path to a gameobject today with a pretty long reference, and I thought if a temp reference wouldn't be better for this situation.
The code:
if (enlargeableButtons[i][j].gameObject.activeSelf && enlargeableButtons[i][j].IsHighlighted())
{
enlargeableButtons[i][j].gameObject.SetIsHighlighted(true, HoverEffect.EnlargeImage);
}
In a case where the path is this long with multiple array indexes to check, it would definitely be faster, but because of the extra object also be more expensive to do it like this:
GameObject temp = enlargeableButtons[i][j].gameObject;
if (temp.activeSelf && temp.IsHighlighted())
{
temp.SetIsHighlighted(true, HoverEffect.EnlargeImage);
}
But how much and would it be worth it?

I seriously doubt you will see any performance gain using a direct reference instead of going through the jagged array.
Maybe if this code is running in a very tight loop with lots and lots of iterations, you might get a few milliseconds of difference.
However, from the readability point of view, the second option is much more readable - so I would definitely go with it.
As a rule - You should design your code for clarity, not for performance.
Write code that conveys the algorithm it is implementing in the clearest way possible.
Set performance goals and measure your code's performance against them.
If your code doesn't measure to your performance goals, Find the bottle necks and treat them.
Don't go wasting your time on nano-optimizations when you design the code.
and a personal story to illustrate what I mean:
I once wrote a project where I had a lot of obj.child.grandchild calls. after starting to write the project I've realized it's going to be so many calls I just created a property on the class I was working on referring to that grandchild and my code suddenly became much nicer.

Declaring GameObject temp just creates a reference to enlargeableButtons[i][j].gameObject. It is extra overhead, but not much. You won't notice a difference unless you're repeating that thousands of times or more.
As a personal rule, if I just need to reference it once, I don't bother with declaring a variable for it. But if I need to use something like enlargeableButtons[i][j].gameObject multiple times, then I declare a variable.

Is it a bad idea to convert byte arrays to strings then parse with regular expressions? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Here's the scenario: I've been recently tasked to write a rs232 serial device communication interface for our existing application. This application has base classes in place to do the actual communication. Basically all I do is accept a byte array into my class then process it.
Part of the issue is that the byte array delivered can be no more than 1000 bytes at a time yet there could be more data waiting to come in that belongs to that transaction. So I have no idea if what was delivered to me is complete. What I am doing is converting that 1000 byte array into a string and stuffing it into a buffer. This buffer then runs a regex to see if what was added creates a complete transaction. I know it's complete if it matches a particular signature (basically a series of control codes at the beginning and end). This buffer will only append data up to 3 times before giving up if no match is found in case of garbage data coming in and no match is ever possible. This isn't a high data volume device so I don't expect tons of data to come pouring in constantly. And the regular expression is only ever executed on, at most, 3000 characters.
So far it works pretty good, but my question is are regular expressions terrible for this? Are there any ramifications in regards to performance for what I'm using them for? My understanding is that regular expressions are typically bad for large volumes of data but I feel this is quite small.

are regular expressions terrible for this?
On the contrary, regular expressions are great for matching patterns in data sequences.
Are there any ramifications in regards to performance for what I'm using them for?
Regular expressions can be written in really inefficient ways, but that is usually a problem with a particular regular expression, not with regular expressions as a technique.
My understanding is that regular expressions are typically bad for large volumes of data but I feel this is quite small.
There is no universal definition of "large" and "small". Depending on a regex engine, your expression is usually translated into a state machine described by the expression. These machines are really efficient at what they do, in which case the size of the data block can be very considerable. On the other hand, one could write a regex with a lot of backtracking, causing unacceptable performance even on input strings of hundred characters or less.

nothing about what you're doing is raising any red flags.
Some things to keep in mind
Don't preoccupy yourself with performance. Just design your program first, and optimize for performance afterwards, and do so only if you have a performance problem.
Some tasks are unsuitable for regular expressions. Regular expressions can't parse XML very well, and they also can't parse patterns like XnYn Without knowing specifically what you're trying to match for with your regex, I can't really analyze whether it's suitable for your problem. Just be careful that you don't have any odd edge cases.
Regex being bad for large amounts of data is not something that I've heard before, and I've been looking around for it online, I'm still not finding much warning against it.
Normally, the most simple solution is the best one. If you can think of a more straight forward and simple solution to your problem, then go ahead with that. If not, then don't worry too much.

is having fewer lines of code always better? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Which is best?
private long sumVals()
{
return (dbReturn("NUns") / dbReturn("TSpd")) * 60;
}
private long dbReturn(string dbField)
{
// ... access db, get value
return retVal;
}
or
private long sumVals()
{
long numUnits = dbReturn("NUns");
long targetSpeed = dbReturn("TSpd");
return (numUnits / targetSpeed) * 60;
}
private long dbReturn(string dbField)
{
// ... access db, get value
return retVal;
}
Is it better to try and put it all onto one line, so there is less code overall, or to spread it out like in the second one?
Is one or the other quicker? Is there a benefit, eg, while compiling?

Your case is simple, so the first one is OK. But in general, I would go for the second one.
It is important that you (and others) can read the code, but you don't need to save memory (fewer lines of code as well as fewer variables).
Your code will be easier to understand and debug if you choose to write it the second way. You also don't have to have a lot of comments if your variable names explain the code well enough, which makes your code easier to read in general. (I am not telling you to stop commenting, but to write code which does not need trivial comments!)
See this question for more answers.

My rule of thumb is to include enough content to fully describe what the intent of the code is, and no more. In my opinion, assigning values to variables only to use those variables immediately is actually less readable. It communicates the flow of the program well enough, but doesn't communicate the actual intent.
If you renamed the function from dbReturn to GetDatabaseValue then I don't think I can come up with a more expressive way to write this function than:
return (GetDatabaseValue("NUns") / GetDatabaseValue("TSpd")) * 60);
This communicates the intent perfectly (notwithstanding the fact that I don't know what "NUns" and "TSpd" mean). Fewer symbols means fewer things to understand when reading the code.
Full disclosure: Including extra symbols does improve debuggability. I write this way when I am first building a function so that I can track down where things go wrong. But, when I am satisfied with the implementation, I compress it down as much as possible for my and my co-workers' sanity.
As far as I can tell, there would be no run-time performance gain achieved by either approach. Compilers are awesome - they do this inlining without your knowledge. The only difference is in the code's readability.

To me, longer is always better. Modern compilers will shrink most code to be very fast. However, being able to maintain code through lots of comments and easy-to-read code is hugely important.... especially if you are one of those guys who have to maintain someone else's code!
So, my vote is the longer version (with a comment explaining what you are doing too!)

How to estimate a project's length in man-hours: Commenting Code [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Does anyone have any suggestions about how to estimate how long it would take to comment and reorganize the code of an entire project?
I just started doing contract work for a company along with another programmer: he's fixing bugs and I'm reorganizing the code. I'd like to make an estimate of how long it would take me to go through the code line-by-line and comment and/or reorganize the code is I go. It's a very large solution: it has two projects, each with multiple files.
It was suggested to me to count all the lines of code in each file, sum it all up, and double your hours to give you padding. It was also suggested that I square the size of the code before estimating. But I don't know how long it's supposed to take to comment, say, 100 lines of code.
Any suggestions would be more than welcome. If it makes a difference, the project is made in Windows Forms using Visual Studio 2012.
Thanks!

I suggest you pick a small random sample (20 lines) and try to reorganize it.
That would give you an idea of how long it takes (if you multiply), and it won't be underestimated, since the randomness of the sample will actually make the work slightly more complicated.
You can also do it two or three times, and see if the variance is small.
Any other method that is not based on you might be less expensive in time, but will not yield results that are tailored on you.
In my opinion this method is a good investment.

First, this is an estimate - estimates are not exact numbers, they are approximations and ranges. The estimate you have at the start may be wildly off once you start getting into it and the estimate would need to be refined. Take into consideration the code of uncertainty when giving an estimate.
There exist many well established models for software estimation. COCOMO II is one of these. I believe that this particular approach has added value to its techniques in that it can work from an already known amount.
A web tool for the COCOMO II can be found at usc. Count up the lines of code you have now. Make an approximation of how many lines of new comments you will need, how much will be able to be reused, and how much will need to be modified. Plug those numbers in. The definitions of how COCOMO II works and all the terms can be found in the usc ftp site
Lets say you have a 10k SLOC existing code of which 75% can be reused, 25% will need to be modified (75% design modification, 100% code modification, ...) and an additional 10% for commenting. There are arguments for and against tweaking the various cost drivers (changing things from 'Nominal' or leaving them as they are).
Plug this in and you get an equivalent size of 2825 SLOC which then translates to 9.2 person months of effort (remember, this isn't just going thorugh the code line by line - but also making sure you have the redesign correct and testing it). Nine months is approximately 1500 work hours.
Consider getting Software Estimation: Demystifying the Black Art which goes into more aspects of what an estimate is and other techniques to do an estimate (this is an estimate by proxy and just one of many techniques).
Remember to save the data on how long it took and your estimate - over time, historical data can help refine estimates.
Further reading on Wikipedia Cost estimation in software engineering

You might be able to find nasty bits by using some sort of code analysis that shows you the complexity of the classes.
Checking for code that is not covered by unit test will also help you to find code that is harder to refactor.

In terms of commenting the code, presumably that means reading every line and describing each method/interesting piece? Ignoring all the usual debate about this, firstly, you have my sympathy, and secondly, I would suggest picking a few classes, and doing the work, and measuring how long it takes: you should be able to extrapolate from there (and add 30% afterwards)
As to reorganising, unless you already know of certain specific large scale refactors you need, my usual answer to "how long will it take" is "how much better do you want it to be?" - and the final answer, always, ends up being a time-boxed amount that is agreeable to both you, and the boss/client. Make a suggestion of x days, and do as much good as you can in that time. Also, someone mentioned integration tests: if this is a viable option, then it will certainly help control the time