|
eyesark wrote: what we view as 'superior' habits
While you may have made your 'case' with your colleague, it was probably in vain, as he/she clearly has a different style that is 'superior' in their minds.
That said, understand the frustration of having someone nitpick about something that trivial, so you get a +5 for combating stupidity!
"Go forth into the source" - Neal Morse
|
|
|
|
|
Just do your own thing if it's comfortable. What other people say are just opinions.
|
|
|
|
|
Spotted myself doing this today:
@Html.UppercaseFirst(Model.SubType.Replace("Document", "document"))

|
|
|
|
|
Forest for the trees.
|
|
|
|
|
What do you get when you cross a joke with a rhetorical question?
---
The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism.
|
|
|
|
|
The IDE didn't knock on your forehead and say, "Hello! McFly!" ? 
|
|
|
|
|
|
A colleague tried to install a Windows service at a customer site. The installation failed with an error in side by side configuration.
But what was the actual problem? In the application configuration file, an entry in appSettings started with
< add key=
The service was to be started at the end of the installation, and failed.
Oh thank you, Microsoft! Even a single space character between the opening bracket and the keyword causes an application startup failure.
And next, ther error message ("side by side configuration") is so useful here.
Two WTFs in one place. Can you top that?
|
|
|
|
|
Ah yes, but the app.config is an xml file and what you have there is not XML.
Regards,
Rob Philpott.
|
|
|
|
|
|
0. Complain to W3C about that. that's Invalid XML.
1. Learn the terms associated with .net development, (start here http://msdn.microsoft.com/en-us/library/aa376307.aspx[^], hint: your error has to do with this:
Quote: Applications and administrators can update assembly configuration on either a global or per-application configuration basis after deployment. For example, an application can be updated to use a side-by-side assembly that includes an update without having to reinstall the application. means that the error could have been on the machine.config file.)
|
|
|
|
|
A config file shall be valid XML, and what you have there isn't valid XML. While I understand the WTF, I wonder if MS can do a good job, even while they follow standards they get mocked upon.
The console is a black place
|
|
|
|
|
Wait until you start working with json in something like MongoDB. A linefeed after the last closing bracket is a serious offence which is next to impossible to discover.
My plan is to live forever ... so far so good
|
|
|
|
|
So I was building an application that presents a list of files matched with info in a database.
Everything was working fine and dandy but horrendously slow.
I quickly found the culprit to be in this function:
Func<string, int> GetIDPart_Of_FileName = FileName => Convert.ToInt32(FileName.Substring(FileName.IndexOf('_') + 1, FileName.IndexOf('.') - FileName.IndexOf('_'))); The files are built in the form of ID_AnotherID.Extension and what I wanted was AnotherID
Can anyone see what I did wrong?
Do note that it was giving correct results.
<edit>fixed typo
|
|
|
|
|
Well I would not use this lambda stuff at all just a plain function. Bu I suppose you're referring to the double call to IndexOf('_') and the Convert I cannot see any use for...
Life is too shor
|
|
|
|
|
Regex should be your friend.
Edit:
string filename = "123_456.txt" ;
System.Text.RegularExpressions.Regex reg = new System.Text.RegularExpressions.Regex
( @"^(?'ID0'\d+)_(?'ID1'\d+)\.(?'Ext'.+)$" ) ;
int id = System.Int32.Parse ( reg.Matches ( filename ) [ 0 ].Groups [ "ID1" ].Value ) ;
modified 12-Sep-14 13:51pm.
|
|
|
|
|
You'd think so, wouldn't you?
Surprisingly, that turns out not to be the case...
Counting Lines in a String[^]
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
I know. 
|
|
|
|
|
I'm noticing your wording my friend.
|
|
|
|
|
Your length is off by one. The decimal point is included. I prefer int.TryParse over Convert.
|
|
|
|
|
And we have a winner.
Amazing that the decimal point is making the conversion more than 3000 times slower.
But since it didn't throw an exception but rather make a correct conversion I actually doubt that TryParse would have made a difference.
|
|
|
|
|
Jörgen Andersson wrote: doubt that TryParse would have made a difference.
Fewer puppies would have been killed. Don't use Convert.
|
|
|
|
|
If I don't expect the conversion to fail I want an exception.
When failure is expected I use TryParse.
There is a reason both exists.
|
|
|
|
|
Yes, in this case Parse is more appropriate. (I just updated my earlier response with an example.)
|
|
|
|
|
Jörgen Andersson wrote: But since it didn't throw an exception but rather make a correct conversion
What version of .NET? I've just tried Convert.ToInt32("42.") in LINQPad for 3.5 and 4.5, and both versions throw a FormatException .
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|