Tag: c#

My CS300 professor at Portland State University just wrote a fantastic blog post about things he commonly sees in student source code – it’s a great read and helpful for reflecting on your own code and best practices:

I’ve read quite a lot of student code over the years. Some of it is quite good. A lot of it is full of predictable badnesses. These notes attempt to enumerate some of this badness, so that you may avoid it.

This is pretty C-centric in its current form. However, many of its lessons are multilingual. This is a living document, so don’t expect it to be the same next time you look at it. In particular, the numbering may change if something gets inserted in the middle. It is revisioned automatically by Drupal, so feel free to point at a particular revision if you care.

And, my own pride and joy (this damn code took me forever, only because I had to do all sorts of research and testing with Regex in C#), the function that will fix relative paths in the combined CSS files by replacing them with absolute paths based on your application root:

One of the common issues in data layer is avoiding duplicate rows from dataset or datatable. I saw many people are writing separate function and looping through the datatable to avoid the duplicates. There is more simple ways available in .Net but people are unaware about this. I thought of writing a blog about this because I saw many blogs which mislead the people from right path. Thers is no need of looping or no need of logic are required to avoid the duplicates.

Following single line of code will avoid the duplicate rows.

ds.Tables[“Employee”].DefaultView.ToTable(true,”employeeid”);

ds – Dataset object

dt.DefaultView.ToTable( true, “employeeid”);

dt – DataTable object

First option in ToTable is a boolean which indicates, you want distinct rows or not?

Second option in the ToTable is the column name based on which we have to select distinct rows.

Simple right, this option is the last one so most of the people didn’t got the time to find it. Now your code will look much cleaner without those junk codes.

While coding in Java recently, I decided to do a little research to see if Java supported the #region directive (or something similar) and found a ton of articles knocking its usage as poor programming style.

Personally, I love the #region directive in C#, as it allows me to keep my code more organized (and yes, I am aware of the exisiting code-folding functionality in Visual Studio). In the files I work with, I’ve become pretty meticulous about organizing the code blocks into regions, partially because I like the organization, and partly because I was previously under the impression that it was good form to keep source files organized in this way. I use the following regions myself, generally:

Private/Protected Members

Public Accessors

Constructors

Public Methods

Protected Methods

Private Methods

(Anything class specific)

I agree with the sentiment in the articles I’ve read that it is *not* good practice to sweep bad code under the rug by hiding it from the developer in a folded #region, but I think that organizing relatively good code into regions like the ones I’ve mentioned above makes it a lot easier to get directly to the code I want to work on.

What do you think? I’m curious to see justifications for/against this directive, and as always, thanks for reading!

LoseThos is for programming as entertainment. It empowers programmers with kernel privilege because it’s fun. It allows full access to everything because it’s fun. It has no bureaucracy because it’s fun. It’s the way it is by choice because it’s fun. LoseThos is in no way a Windows or Linux wannabe — that would be pointless. LoseThos is not trying to win a prize for low resource usage or run on pathetic hardware. Low line count is a goal, though. It’s 100,000 lines of code including a 64-bit compiler, tools and a graphics library. It’s strictly 64-bit and could be configured to function with 32 Meg or less RAM, but who cares! Where do you get a x86_64 machine with less than 32 Meg RAM? With no multimedia, it’s hard to run out of memory on a modern home computer.

…

LoseThos was designed from scratch with a clean slate and has no compatibility with anything else. Source code is ASCII plus binary graphics data. It has a new language roughly based C/C++. It’s more than C and less than C++ so, maybe, it’s C+. I took every opportunity to improve things once I made a clean break with the past. That’s another reason LoseThos has value — it is innovative.

I started with a command line like this:Dir(“*.*”);

I added default parameters from C++:Dir();

I said, “parentheses are stupid.”Dir;

Now, I have a language which looks a little like pascal. It also doesn’t have a main() routine — any statement outside a function executes immediately, in order. The command line feeds straight into the compiler (not an interpreter) and it doesn’t have that bullshit errno crap for return values — command line commands are regular C+ functions.

Another shitty move by (Alcatel-)Lucent, who wrecked Bell Labs and blew all of my stock money…

Bell Labs Kills Fundamental Physics Research

By Priya Ganapati

After six Nobel Prizes, the invention of the transistor, laser and countless contributions to computer science and technology, it is the end of the road for Bell Labs’ fundamental physics research lab.

Alcatel-Lucent, the parent company of Bell Labs, is pulling out of basic science, material physics and semiconductor research and will instead be focusing on more immediately marketable areas such as networking, high-speed electronics, wireless, nanotechnology and software.

The idea is to align the research work in the Lab closer to areas that the parent company is focusing on, says Peter Benedict, spokesperson for Bell Labs and Alcatel-Lucent Ventures.

“In the new innovation model, research needs to keep addressing the need of the mother company,” he says.

That view is shortsighted and may drastically curtail the Labs’ ability to come up with truly innovative discoveries, respond critics.

“Fundamental physics is absolutely crucial to computing,” says Mike Lubell, director of public affairs for the American Physical Society. “Say in the case of integrated circuits, there were many, many small steps that occurred along the way resulting from decades worth of work in matters of physics.”