Contrast duplicating, inlining and premature optimizing. Or the fact the "pattern" may not yet have fully materialized in the mind. It's not the first time one has pulled together "similar" code only to realize you just dug a deep pit because you didn't consider the full impact. Which is very easy in the "agile" environment where they pump out bits of code in ignorance of the big picture. As for the ToSTring() example, I use xxxAsSomething() ... which inevitably winds up including xxxAsSomethingDifferent(), etc. I've now established a pattern that creates functions out of everything ... even "one-timers". And then programming becomes a real drag. It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food

to make project like building etc.

I've been looking at repository pattern implementations (using .Net and EF). Many of them aren't selective. One of the most common methods is GetByID. This gets the whole record. Is this really bad? It will return one record, and in most systems it'll use the primary key. One of the most shocking things I have seen is List GetAll(). This returns ALL records in a table. This is clearly going to become an issue in large systems. Another way some systems work is by using DDD and having aggregates return all related data. This tends to make the code simple, but I have doubts about scalability. Has anybody got experience with a system like this?

There are a number of other tools. Pros and cons, you could analyze yourself. E.g. http://xunit.codeplex.com/wikipage?title=Comparisons[^]. Apps - Color Analyzer | Arctic | XKCD | Sound Meter | Speed Dial

I think part of the problem is with the difficulty of writing testable code. Eg. How would somebody write good tests if they don't understand dependency injection? You also get people who write functions that are hundreds of lines long and writing testable code would be difficult for them. jesarg wrote: If you had a code sergeant who enforces good unit tests with an iron fist, you could end up with a robust, uniform system, but most developers will screw up the whole test suite without realizing it. Would you have a happy and productive team though? Devs will often skip the tests when they are under pressure, and when they're under pressure they probably wouldn't appreciate criticism.

Func is a generic type, you'd usually have information about the parameters. Lambdas are really nice for simple functions (in the mathematical or FP sense), where the boilerplate text for defining a method would be a significant portion of the code, and where the calculation type is simple enough that everything can be inferred (by the reader; the computer has no problem anyway!). I've also seen them used for event handlers, where the parameter types are well known. LINQ to SQL, if used correctly, creates queries very similar to what you'd make yourself, and manages the result in a much more friendly fashion. It doesn't have that much to do with lambdas though apart from the query related functions that take a lambda parameter.

I limit my check-ins to pieces of completed functionality (or fixes).  This makes it much easier to undo a piece of work if necessary.  However, I shelve[^] my code frequently (several times a day) to reduce the risk of losing my work due to a hardware or software glitch on my workstation.  Shelving also enables us to safely do code reviews that require executing someone else's changes. /ravi My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com

I am an almost religious advocate of the DRY principle (I have broken it a few times but either through extreme need or the decision wasn't mine to make.. and believe me, in that case, i fought it bitterly) In my experience, there are a LOT of developers out there happy to throw the DRY principle away and they cite the following excuses: - Time constraints - Budget constraints - Too high impact on existing (flawed) design - Inexperience (excuse usually given by someone else on their behalf) Personally i find i generally design a system in my head, then as I'm coding it spot areas where I'm in danger of breaching the DRY principle and, in rooting these out, a better design surfaces. I guess there are two types of developer, the first measures their success in designing and building an application by the elegance of the end design and its adherence to good coding practice, the second measures their success by meeting performance targets. I have worked in environments where some developers were bringing in unmaintainable messes early and under budget and were praised by the PHBs as examples for the rest of us coders (scraping by the budgets with elegant solutions) Sloppy coding can give you a short-term gain, but its gonna bite you in the arse eventually IsRanting = false; ;P

A lot of methods that are only 1 line long can be a little annoying too. Of course if it's a public interface and you want to protect your right to change implementation, then it should still be a method. And there are other good reasons, but just breaking up the code "because you can" isn't a good reason. You might imagine a large house of 10,000 square feet. If that were just one huge room, the house wouldn't be very usable. If there were appropriate sized rooms, of 100 to 300 square feet each or so, then you have a very usable house. If you have many rooms of only 4 square feet each, then you once again have an unusable house. In other words, break it down to an appropriate level, but no more. There is a quote supposedly by Pascal that goes something like "I'm sorry this is so long, I didn't have time to make it shorter." Making good methods that are short enough (but not too short) takes time to do correctly. Yes, reading and maintaining long code (or any code) is a skill. You might want to look at Brownfield Application Development in .NET by Belchem and Baley. What do you mean when you say your code is "very unique"? All else being equal, being different is not good. All it does is slow people down as they try to read a style they're not used to. So they might find it hard to work with, but if you're doing something good then maybe they should be copying you. My kneejerk response is that you're trying to be too clever. Clever is sometimes good but usually not. modified on Wednesday, November 17, 2010 9:50 AM

I find testing (and writing tests) invaluable.  In fact, it's the only reason I sleep soundly at night (no, really).  I'm working on some low-level frameworky stuff (that has to work and has to work fast) and end up writing slightly higher level tests than the ones mentioned in your post. I find them to be more useful (i.e. akin to how my APIs are used) than traditional unit testing. To answer your question, I probably wouldn't write tests that check table reads and writes - instead, I'd write tests for the APIs that end up calling them.  I hope this makes sense. /ravi My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com

Luc Pattyn wrote: change all private attributes to protected ones that was exagerated, it should read: change private attributes to protected ones as required... Yes, making everything protected (or public) is not highly regarded as it opens the door more than may be required by the app itself. I listed some possibilities and already said they all have some drawback; do you have a better solution? :) Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] I only read code that is properly formatted, adding PRE tags is the easiest way to obtain that. All Toronto weekends should be extremely wet until we get it automated in regular forums, not just QA.

I hate to admit it, but I've found code like that here from a previous developer. It's also in C#, but the delimiter is a newline. Maybe you have our old developer? public string FormatBarContent(string foo1, string foo2, string f003, // ... string foo14, ) { StringBuilder sb=new StringBuilder(); sb.Append(foo1); sb.Append("\n"); sb.Append(foo2); sb.Append("\n"); // ... sb.Append(foo14); // sb.Append("\n"); return sb.ToString(); } And some of the foo's have been converted from numbers to strings. The routine that gets this string immediately Split()'s it and parses the numbers back into numbers. None of the data ever needs to leave the current thread. Don't they know what a struct is? -- T

Member 4487083 wrote: I'm should there will be lots of opinions, but do you think it's reasonable for me to dislike VB? Other people don't like VB.NET, C# or C++, and opt for Python, Ruby or even Pascal[^]. So you're not so sharp on VB. The *cool* news here is that you can team up with a VB.NET programmer, even if he/she isn't too keen on C# - you can both write your .NET classes in your own language :) I are Troll :suss:

Databinding is a great feature, a base to zero code tricks. If you follow rules properly you will found it very helpfull and very thin front end pages. Share your experience with others Check my Blog...

Pete O'Hanlon wrote: Never, ever, bad mouth anybody. I don't want to hire somebody who trashes the last guy she worked for. If you are asked why you want to leave your current job, have something ready. I usually find that the old "I feel that I've reached the maximum of my potential in my current position, and I'm looking for a dynamic team where I can grow and develop new skills" is an effective way to bat this one into the undergrowth. while i agree with this for a number of reasons, it has always bothered me for not being able to just come out and say : 'i work for/with a bunch of scumbags/lepers/whatever - this was only revealed to me after i was hired and got to know them - i would like to rectify this now' it essentially encourages lying/political correctness, and then we wonder why the world sucks so much come on, we all know that often there is not a personality fit and we want a change - why not be able to say it like it is? </rant off> Opium is my business. The bridge mean more traffic. More traffic mean more money. More money mean more power. Speed is important in business. Time is money. You said opium was money. Money is Money. Well then, what is time again? icalburner.net