We Keep Coding

Does starting method names with "Do" conform to some kind of standard? [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 4 years ago.
Improve this question
For some reason, a couple of members of my team habitually starts method names with "Do"
e.g.
public void DoReopenLeads()
public void DoProcessBaloney()
Now, I'm a "learn on the job" kind of a guy and haven't had any formal code training, so I don't know whether this is an industry accepted coding standard.
To my mind, it seems a bit dumb, as all methods "Do" something or other...
Coding standards for our team doesn't cover how to name methods (other than saying what the function does in fairly clear English)

There are no such standard. Maybe this is local "style". Prefix "Do" can be useful if there are several methods/functions with same words after "Do" like: PrepareProcess, LoadProcess, FinishProcess - then DoProcess will be normal.

There is no kind of definition that each method should start with "Do".
One principle from Clean Code (I love and recommend the book from Robert C. Martin) for naming methods is that you should not look into a function in order to know what the function does. So the naming has to transport the meaning.
Methods should be verbal phrases, because they actual "do" something with or on the data. But just beginning all method with a Do prefix only adds useless information. Being more specific makes it easier to accomplish the "Clean Code" goal.

Usually for methods that represent actions method's name starts with a verb. “do” or “does” are auxiliary verbs and rarely they add meaning.
Btw, take a look at this: C# Coding Conventions

Whilst this topic is kind of oponionated I would like to share some soft guidances I have found.
The DoFactorys C# Coding Standards and Naming Conventions only states that:
use noun or noun phrases to name a class
A rather useful guide of AvSol C# Guideline maintained by Dennis Doomen states that:
Name methods using a verb like Show or a verb-object pair such as ShowDialog. A good name should give a hint on the what of a member, and if possible, the why.
Also don't include And in the name of a method. It implies that method is doing more than one thing, which violates the single responsibility principle...
In the end, the are no such official guidelines exist written in stone. Your workspace and domain culture should drive creating your own guidelines.
For a good start I suggest you to read Domain-Driven Design: Tackling Complexity in the Heart of Software written by Eric Evans. It contains a section called Ubiquitous Language which might help you to learn how to create and evolve your shared language by closely consulting with your domain experts AND fellow coworkers. Your code could also follow this common language, so your codebase could tell "stories" or use-cases by reading it.
An other good reference about the UL is written by Andrew Whitaker, where he writes that:
Having a ubiquitous language improves the coherence of the code base and keeps everyone on the same page.

Why isn't string concatenation automatically converted to StringBuilder in C#? [duplicate]

This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Why is String.Concat not optimized to StringBuilder.Append?
One day I was ranting about a particular Telerik control to a friend of mine. I told him that it took several seconds to generate a controls tree, and after profiling I found out that it is using a string concatenation in a loop instead of a StringBuilder. After rewriting it worked almost instantaneously.
So my friend heard that and seemed to be surprised that the C# compiler didn't do that conversion automatically like the Java compiler does. Reading many of Eric Lippert's answers I realize that this feature didn't make it because it wasn't deemed worthy enough. But if, hypothetically, costs were small to implement it, what rationale would stop one from doing it?

But if, hypothetically, costs were small to implement it, what rationale would stop one from doing it?
It sounds like you're proposing a bit of a tautology: if there is no reason to not do X, then is there a reason to not do X? No.
I see little value in knowing the answers to hypothetical, counterfactual questions. Perhaps a better question to ask would be a question about the real world:
Are there programming languages that use this optimization?
Yes. In JScript.NET, we detect string concatenations in loops and the compiler turns them into calls to a string builder.
That might then be followed up with:
What are some of the differences between JScript .NET and C# that justify the optimization in the one language but not in the other?
A core assumption of JScript.NET is that its programmers are mostly going to be JavaScript programmers, and many of them will have already built libraries that must run in any implementation of ECMAScript. Those programmers might not know the .NET framework well, and even if they do, they might not be able to use StringBuilder without making their library code non-portable. It is also reasonable to assume that JavaScript programmers may be either novice programmers, or programmers who came to programming via their line of business rather than a course of study in computer science.
C# programmers are far more likely to know the .NET framework well, to write libraries that work with the framework, and to be experienced programmers who understand why looped string concatenation is O(n2) in the naive implementation. They need this optimization generated by the compiler less because they can just do it themselves if they deem it necessary.
In short: compiler features are about spending our budget to add value for the customer; you get more "bang for buck" adding the feature to JScript.NET than you do adding it to C#.

The C# compiler does better than that.
a + b + c is compiled to String.Concat(a, b, c), which is faster than StringBuilder.
"a" + "b" is compiled directly to "ab" (useful for multi-line literals).
The only place to use StringBuilder is when concatenating repetitively inside a loop; the compiler cannot easily optimize that.

Converting a VB.NET Project to a C# Project [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
I'm looking for a tool (paid or OSS) to convert a mid-sized VB.NET project to a C# project. I've searched StackOverflow and have found a few questions/answers, but most suggest .NET Reflector or online copy/paste single file tools. Reflector doesn't seem to fit the bill as it will convert an assembly, but we're looking for a whole-sale project converter which will maintain the project including file names, comments, etc.
We're fully willing to manually address items that cannot be automatically converted, but would like to start off with a fairly comprehensive converted project.
One recommendation we found is Elegance Technologies' CSharpener for VB.NET - http://www.elegancetech.com/csvb/csvb.aspx. Based on their site, it hasn't been revved since pre-VS 2008.
Recommendations will be appreciated.

SharpDevelop is an open source IDE and it allows you to covert between VB and C#.

Do be aware that there are some things which can be done nicely in VB.net that cannot be done nicely, if at all in C# (and vice versa). Two of note:
In vb.net, declaration-initializations (e.g. "Dim Foo As Bar = Whatever") in a derived class occur after the base constructor has run, and can make reference to the object being constructed. In C#, such declaration-initializations occur before the base constructor is run, and cannot reference the object under construction. One could probably move all such initialization to the constructor, but if there are multiple constructors that may require the creation of redundant code.
In vb.net, a Catch statement may include a condition (e.g. Catch Ex As FancyException When Ex.SomeProperty = 9). In C#, the only way to a achieve a somewhat similar result is to catch an exception and then decide if it meets the necessary criteria, rethrowing if not; this will yield different semantics in a number of ways. Among other things, at the time the When clause is evaluated, Finally statements which will be tripped by the exception will not yet have run, so allowing the state of the system to be captured. Further, if break-on-unhandled-exception is set, and no "When" condition is satisfied, the debugger will break at the location where the original exception occurred. If the exception had been caught and rethrown, the debugger would break at the re-throw.
I would think an IL-to-C# translator might do an okay job of moving initializations to an object's constructors, though that lead to some annoying repetition. I don't think there's any way for C# code to match the semantics of VB.net's exception handling, though.

Two words: A programmer.
If you want it to be the most bug free and just work hire a programmer.
A quick google turns up http://www.freelancer.com where you can hire a one time programmer.

If you're not satisfied with SharpDevelop, TangibleSolutions will provide support with their converters to ensure your happiness.

SharpDevelop is quite good, but at my company we've found VBConversions to provide a much more complete conversion. It's a commerical app though, but for the time saved over SharpDevelop it was a no-brainer for us.
As a specific example, one thing we found that SharpDevelop didn't convert correctly was VB indexes, which use curvy brackets. It seemed unable to distinguish between indexes and method calls so didn't convert the indexes to square brackets. VBConversions converted them fine. This one thing made it worth its purchase for us.

Looking for example program written in different languages [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
As a way to understand the differences between OOP and Procedural languages I was looking for a sample program written in C and C++ or C# or Java. I just want to see the different approaches to the same problem to help me get a sense of the real differences. Does anyone know where I can find a tutorial like this?

I don't think this is likely to teach you much. The program has to have a certain size before the differences between different programming paradigms really show. And people aren't likely to write identical copies if the same program in different languages unless the program is trivial.
Most real-life examples would also be polluted with a lot of extra noise, things that can be done within the standard library of one language, but requires third-party libraries in another. And the programmer who wrote it may be more familiar with one language than another, so his implementation in some languages isn't representative of how it "should" be done.
You're more likely to learn the difference between these paradigms the usual way. By learning what each means, and how to use it.

I recommend the 99 bottles of beer website

You can always look at Project Euler. People solves the same problems in a many different languages. Most people will post their solutions that you can access after you solve the problem also.

Take a look at The Computer Language Benchmarks Game. It's got implementations of various programs in just about every language you could imagine.

This might be a bit simple for your purposes but the Hello World Collection is always fun to look through.

Rosetta Code has a wealth of data but very little of it is related to the procedural/object-oriented distinction. You should also see their collection of related sites.

Black Scholes in multiple languages has plenty of implementations of the Black-Scholes formula.
The formula is implemented in Objective-C/iPhone, F#, Autoit, Fortress, Lua, APL, SAS, Mathcad, J, MEL, Postscript, VB.NET, Clean, Ruby, Lisp, Prolog, PL/SQL, LyME, ColdFusion, K, C#, HP48, Transact SQL, O'Caml, Rebol, Real Basic, Icon, Squeak, Haskell, JAVA , JavaScript, VBA, C++, Perl, Maple, Mathematica, Matlab, S-Plus, IDL, Pascal, Python, Fortran, Scheme, PHP, GNU, gnuplot.

Somebody posted Evil Walrus / ReFactory on Reddit the other day:
http://www.refactory.org/

Here are two programs that implement n-body
Java implementation
C implementation
What differences do you find between them?

Consider the implementation of a snakes and ladders games
In a procedural design we might write a function like
function move(int n) {
pos += n;
switch(pos) {
case 6: pos = 10; break;
case 12: pos = 4; break;
case 15: pos = 32; break;
case 16: pos = 8; break;
// ...
}
}
in an object design language we would create a linked list of Square instances, with some Ladder and Snake instances that branch to other squares.
class Square
def initialize(next)
#tokens = []
#next = next
end
def next(n)
n == 0 ? self : next.next(n-1)
end
def move(token,n)
tokens.remove(token)
target = self.next(n)
target.tokens << token
end
end
class SnakeOrLadder < Square
def initialize(next,branch)
super(next)
#branch = branch
end
def next(n)
# goes to branch when landing on this square!
n == 0 ? #branch : next.next(n-1)
end
end
as you can see, we implement the game rules in the objects as well as the way they are composed (rather than in a switch case statement). This has the advantage that
it is simple to add new game rules at development time, you'll just write a new subclass of Square
it is simple to change the layout of the game at runtime (might sound strange for a game, but for your average business app, this is what you want)
this flexibility is what makes OO so powerful.

What's the best way of parsing strings? [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
We've got a scenario that requires us to parse lots of e-mail (plain text), each e-mail 'type' is the result of a script being run against various platforms. Some are tab delimited, some are space delimited, some we simply don't know yet.
We'll need to support more 'formats' in the future too.
Do we go for a solution using:
Regex
Simply string searching (using string.IndexOf etc)
Lex/ Yacc
Other
The overall solution will be developed in C# 2.0 (hopefully 3.5)

Regex.
Regex can solve almost everything except for world peace. Well maybe world peace too.

The three solutions you stated each cover very different needs.
Manual parsing (simple text search) is the most flexible and the most adaptable, however, it very quickly becomes a real pain in the ass as the parsing required is more complicated.
Regex are a middle ground, and probably your best bet here. They are powerful, yet flexible as you can yourself add more logic from the code that call the different regex. The main drawback would be speed here.
Lex/Yacc is really only adapted to very complicated, predictable syntaxes and lacks a lot of post compile flexibility. You can't easily change parser in mid parsing, well actually you can but it's just too heavy and you'd be better using regex instead.
I know this is a cliché answer, it all really comes down to what your exact needs are, but from what you said, I would personally probably go with a bag of regex.
As an alternative, as Vaibhav poionted out, if you have several different situations that can arise and that you cna easily detect which one is coming, you could make a plugin system that chooses the right algorithm, and those algorithms could all be very different, one using Lex/Yacc in pointy cases and the other using IndexOf and regex for simpler cases.

You probably should have a pluggable system regardless of which type of string parsing you use. So, this system calls upon the right 'plugin' depending on the type of email to parse it.

You must architect your solution to be updatable, so that you can handle unknown situations when they crop up. Create an interface for parsers that contains not only methods for parsing the emails and returning results in a standard format, but also for examining the email to determine if the parser will execute.
Within your configuration, identify the type of parser you wish to use, set its configuration options, and the configuration for the identifiers which determine if a parser will act or not. Name the parsers by assembly qualified name so that the types can be instantiated at runtime even if there aren't static links to their assemblies.
Identifiers can implement an interface as well, so you can create different types that check for different things. For instance, you might create a regex identifier, which parses the email for a specific pattern. Make sure to make as much information available to the identifier, so that it can make decisions on things like from addresses as well as the content of the email.
When your known parsers can't handle a job, create a new DLL with types that implement the parser and identifier interfaces that can handle the job and drop them in your bin directory.

It depends on what you're parsing. For anything beyond what Regex can handle, I've been using ANTLR. Before you jump into recursive descent parsing for the first time, I would research how they work, before attempting to use a framework like this one. If you subscribe to MSDN Magazine, check the Feb 2008 issue where they have an article on writing one from scratch.
Once you get the understanding, learning ANTLR will be a ton easier. There are other frameworks out there, but ANTLR seems to have the most community support and public documentation. The author has also published The Definitive ANTLR Reference: Building Domain-Specific Languages.

Regex would probably be you bes bet, tried and proven. Plus a regular expression can be compiled.

Your best bet is RegEx because it provides a much greater degree of flexibility than any of the other options.
While you could use IndexOf to handle somethings, you may quickly find yourself writing code that looks like:
if(s.IndexOf("search1")>-1 || s.IndexOf("search2")>-1 ||...
That can be handled in one RegEx statement. Plus, there are a lot of place like RegExLib.com where you can find folks who have shared regular expressions to solve problems.

#Coincoin has covered the bases; I just want to add that with regex it's particularly easy to end up with hard-to-read, hard-to-maintain code. Regex is a powerful and very compact language, so that's how it often goes.
Using whitespace and comments within the regex can go a long way to make it easier to maintain regexes. Eric Gunnerson turned me on to this idea. Here's an example.

Use PCRE. All other answers are just 2nd Best.

With as little information you provided, i would choose Regex.
But what kind of information you want to parse and what you would want to do will change the decision to Lex/Yacc maybe..
But it looks like you've already made your mind up with String search :)