This is my Hello World post

[Olive34]

Hello.
I'm a web developer just taking a short break from converting a mess of legacy C# code into something more manageable. It's nice to be here.

[Dani]

Hi and welcome to DaniWeb. Good luck!!! Be sure to comment really thoroughly as you go and take advantage of your IDE's refactoring functionality.

[rproffitt]

That's a tall order. One person's system is another person's mess.

Does this C# app or apps have a Design Document?

When I encounter such systems it's usually missing the basic documentation. Without that you are left to navigate the code and divine what the intent and design was. Put another way, code on its own is rarely enough to understand what the code or design is supposed to do.

[Reverend Jim]

Welcome to Daniweb. What was chosen to replace C#?

[Dani]

I think he’s just refactoring the existing spaghetti code, if I understand correctly.

[Olive34]

The C# (and aspx) app does have a bunch of design documents, it's a very old Army system, so yeah, TONS of regulations. So we can't really change any functionality, but we can make a 1,000 line method more readable by refactoring as much as possible. It is eventually going to be replaced with MVC, but not for a while yet. For now, we still have to work with the old C#. I'm okay with that though, C# is what I'm most familiar with. I haven't been ordered 'fix all of this' or anything. The task is to fix one issue the users reported, which has been done. But the code is a mess, so while I'm fixing the issue I'll try to make the rest of it better as well.

As for commenting, I'm of the opinion that well written code doesn't need much commenting. If you can tell the purpose of the method or variable by it's name, for example, then no comments are needed.

(and I'm a she)

Thanks for the replies/welcome. :)

[rproffitt]

I'm of a different school about legacy code maintenance. I've worked in both the military and commercial spaces but in both it's all about the money.

We don't refactor for the sake of refactoring. We fix the issue with the minimum of changes and time/money invested. Yes, once in a while you will have a team member that wants to correct the entire set of code but will the budget and time allotted support such? In all the big systems I've been on, the answer was always no.

About the documentation. The documentation is about the system, not the method variable names. It could get down to such detail depending on the project lead and of course, the budget and time.

-> And this will upset the usual academic. Get in, fix it, get out and move on to the next job.

[Dani]

My code is self-commenting as well. ;)

I have always heavily commented my code so I just do it subconsciously as I write. I also make sure to comment why I did something a certain way, so that if I have to go back and look at it 10 years later, I’ll refresh my memory that there was a reason it was done that way and (perhaps) the more obvious way to do it wouldn’t work for reasons.

[Dani]

Also, just so that Olive realizes as she’s new here, what I was referring to is the platform that powers this site, DaniWeb, which I’ve been working on since 2002.

[rproffitt]

Old saying that I have to share:

When I wrote this code, God and I knew how it worked.

Now only God knows

[Reverend Jim]

This post has no text-based content.

[Olive34]

I agree with the idea that you should comment when it’s not obvious why the code is written that way. Since my boss told us to include summaries for new methods, usually I just put those type of comments there. Then the comments don’t end up in a different place or obsolete and left there when code is refactored and they should always make sense.

I certainly don’t want to refactor the entire code base although the site would probably run better. It would take longer than I have left to work to fix it all, and we are eventually going to switch to MVC.

We definitely have time right now. We have been waiting for several months for the official documents telling us what we are supposed to be doing. We know, but it’s not official. Officially, we have “nothing” to do.

So, since everything I have been assigned is fixed, I’m updating a few methods where this fix is. It makes reading the code a lot easier and is easier to debug and test my changes. And gives me something to do as I wait for official requirements.

Also, maybe “legacy” was a bad choice of words. The site is still used daily by Army personnel all over the world. It’s just old, slow and in need of repair. The servers are not great either, so anything we can do to improve the site is favored by the bosses.

[Reverend Jim]

Since comments are supposed to reflect what the code does, I have gotten into the habit (over many years) of writing my comments first and then adding the code. If the code is obvious, comment it anyway. What is obvious to you now may not be obvious to you (or someone else) down the road.

[Reverend Jim]

Here's a gotcha from years past:

Our AGC/SCADA system was written mostly in FORTRAN. While making a very small modification to a piece of code I did a small reformatting to correct bad indentation. In the process, one line became one character longer. In those bygone days, columns 73-80 were reserved for line numbers (at one time punch cards used this formatting) even though line numbers were not used on disk based files.

Assembler modules could be called with missing parameters by using commas with no values such as

CALL SOMECODE(p,x,v,,,,,,,,m)

Unfortunately, in my case, the call was very long and spanned two lines so one of the commas got pushed into column 73 and was therefore ignored by the compiler. That completely broke the code in a way that took two weeks of debugging to figure out (a visual inspection showed nothing wrong).

Short version - be very careful when refactoring.

[Dani]

My code comments are typically just notes to myself to refresh my memory of why I did something a certain way, or tongue-in-cheek jokes to myself. It's very heavily commented though. Oh the joys of being the only one working on this platform for two decades.

[Olive34]

I do write lots of notes to myself as I’m working on things, but it’s not welcomed by or beneficial to the other devs on the team. So I get rid of them when I’m done testing and before merging with everyone else’s code changes. But at my first job when I was the only developer, I wrote a couple of pages of comments to myself in one program. It was probably too much! ☺️

[bravomorris9]

Hii! Nice to meet you....