asp.NET with C#

Okay so I just got an ENTERPRISE entry level job-- I really like C# so far, but some shit is ridiculous, and it isn't my fault or the language's fault at all. I literally had to write this line the other day:

IEnumerable<Popsicles.Objects.DAL.Sproc_WebSite_LoadUniquePopsicleCountsResult> ab = SqlHelper.GetRecords<Popsicles.Objects.DAL.Sproc_WebSite_LoadUniquePopsicleCountsResult>("Sproc_WebSite_LoadUniquePopsicleCounts @WebsiteID=" + ws.WebSiteID.ToString(), new string[] { });

... On top of that, I had to filter those results with LINQ twice instead of just reshaping the stored process to fit my needs from the database. Even more horrible, I had to write this function to help with that:


protected int GetPrice(Sproc_WebSite_LoadUniquePopsicleCountsResult dl, PopsicleSite.WebSiteSetup.WebSite ws)
    {
        Popsicles.Objects.BusinessObjects.WebSiteBO.PriceField pf =  Popsicles.Objects.BusinessObjects.WebSiteBO.GetPriceFields(dl, ws.NewPrimaryPriceField, ws.NewPrimaryPriceFieldLabel, ws.NewSecondaryPriceFieldLabel, ws.SecondaryPriceFieldLabel, ws.PrimaryPriceField, ws.SecondaryPriceField, ws.PrimaryPriceFieldLabel, ws.SecondaryPriceFieldLabel).Where(z => z.isPrimary).FirstOrDefault();
        if (pf != null)
            return pf.Price;
        else
            return 0;
    }

what the FUQ.. Keep in mind that I have nothing to do with most of this shit that is being called/instantiated, I'm just trying to do my job of EXPERT WEB DEVELOPMENT.

Is this what OOP has come to? IS IT REALLY LIKE THIS IN THE REAL WORLD? I think most of this stuff is on the bill for re-factoring, and it's true that the development team doesn't really have much time, and it's also true that I really probably don't know what I'm talking about, but still...

I think I'm keeping to 1 and 2 character variable names just to keep from going insane

_{object references changed to cover my anus}

Welcome to the new millennium.

You can make aliases for namespaces and for classes within a namespace; that might help a little.

 • using WBO = Popsicles.Objects.BusinessObjects.WebSiteBO;
 • using LUPCR = Popsicles.Objects.DAL.Sproc_WebSite_LoadUniquePopsicleCountsResult;

You can make these aliases local to a code block:
namespace X {
    using S = System.Runtime.Serialization;

    namespace Z {
        using XS = System.Xml.Serialization;
    }
}

Also, use var where you feel like it, assuming your ＥＮＴＥＲＰＲＩＳＥ ＢＥＳＴ ＰＲＡＣＴＩＣＥＳ allow it. That way you don't need to type things out twice (as often).

It still won't save you from having such an enterprisely architected solution, but it might help.

Sometimes I wonder if such namespace fragmentation is a good thing. It does have the advantage of making symbol conflicts almost inexistent, but it also leads to fairly bloated code.
In Lisp, the package system is pretty opaque and non-hierarchical, which isn't that bad, but it may lead to symbol conflicts at time, albeit it's a not very hard to avoid problem, if one knows what they're doing. I wonder how the package system would look if one tried to use something like C# or Java's hierarchical namespaces for packages. I've seen some people use such things, but it seems too much of a PITA in the end.

>>3

This is excellent advice, thank you.

MSDN is telling me that  var is ｃｏｎｓｉｄｅｒｅｄ　ｈａｒｍｆｕｌ　to test driven development because you aren't offered IntelliSense on variables not statically typed HURR DURR


>>4

I must agree that it is a pain in the ass. I don't understand why I must declare

using Popsicles.Objects.BusinessObjects;
using Popsicles.Objects.DAL;
using Popsicles.Objects;

and instead cannot just declare


using Popsicles.Objects;

and have Popsicles.Objects.DAL and Popsicles.Objects.BusinessObjects available to me.

>>4
The essential tension in programming languages is whether to force convention or not. Everyone agrees code formatting is good; not everyone agrees with FIOC. Everyone agrees name conflicts can be nasty bugs; not everyone agrees on implementations of namespaces.

Think of the need to create needlessly complicated designs as job security.

>>7
But that's just sad, isn't it?

Considering if the code was just documented then ``anyone'' could do it. Why is this attitude prevalent?

you aren't offered IntelliSense on variables not statically typed
That may be true, but it's a poor argument. IDEs should infer obvious details like this, so that programmers don't have to.

>>8
All of commercial software development is sad.

I came across something like this on my previous job, where they created ENTERPRISE LEVEL C SOLUTIONS

/* Function to duplicate the given string */
char *strsave (char *str)
{
    return strdup(str);
}


Enterprise - Solving problems where there aren't any!

>>11
solving problems where there aren't any
strdup

>>11
Likely some NIH moron wrote his own half-assed buggy utility function, and then someone came in later, facepalmed, and did a quick and uninvasive hack just to fix the damn crash.
I'm betting on
char *strsave (char *str)
{
    char a[50];
    if ((strln(str)) > 0)  // speed optamisacien for nul strings
  return "";
    strcpy(str, a);
 return a;
}

>>13
ENTERPRISE NONSOLUTION

char *strsave(char *str)
{
     return str;
}

>>5
var variables are statically typed.

>>8
Any work not done by a manager is ``trivial´´.