The History of the VCS

  • Steve Jones - SSC Editor

    SSC Guru

    Points: 716562

    Wayne West (9/14/2015)


    I'll be honest: I currently do not use a version of VCS. I did back in the Dos days using BRIEF, someone came out with a source control package called Sourcerer's Apprentice that integrated quite nicely. I tried to get VCS at my previous gig but it never happened. At my current gig, I'm more optimistic. I'm going to the Denver SQL Saturday this weekend and doing the pre-con session on DLM and I'm hoping that'll give me the information that I'm looking for to get some tools.

    See you there, Wayne,

    We'll be looking at Subversion and databases, with the Redgate tools, but you'll have an idea of how you can do things with other VCSes.

  • roger.plowman

    SSChampion

    Points: 10173

    Hate to be argumentative, but such zen code is the sound of one hand clapping...

  • pparsons

    Old Hand

    Points: 397

    DVCS all the way! Having started with a "first generation" VCS and coordinating the changes necessary between multiple developers, then progressing to SVN and now to GIT there is no comparison, GIT has it all and is offline 🙂

  • Lynn Pettis

    SSC Guru

    Points: 442167

    Wayne West (9/14/2015)


    I'll be honest: I currently do not use a version of VCS. I did back in the Dos days using BRIEF, someone came out with a source control package called Sourcerer's Apprentice that integrated quite nicely. I tried to get VCS at my previous gig but it never happened. At my current gig, I'm more optimistic. I'm going to the Denver SQL Saturday this weekend and doing the pre-con session on DLM and I'm hoping that'll give me the information that I'm looking for to get some tools.

    Going to miss the Denver SQL Saturday. Coaching a U18 Girls Soccer Team made up of all Fountain Fort Carson High School Lady Trojan soccer players plus two freshmen and sophomore transfer that will be trying out for the Lady Trojans in the Spring.

  • Lynn Pettis

    SSC Guru

    Points: 442167

    roger.plowman (9/14/2015)


    Hate to be argumentative, but such zen code is the sound of one hand clapping...

    Not as good at commenting my code as I would like, but working on it.

    I have seen commented code where the comments just got in the way and provided no valuable information beyond what was already there in the code itself. For example:

    -- set @Debug = 1

    set @Debug = 1;

    Yes, I have seen this. What in the world does the comment add to this piece of the code.

    Describe what the procedure/script/trigger/function/whatever is expected to do, provide a history of changes and way they were made, you may even include some simple test code to run to verify the code works. Just make sure if the code changes that the test code changes as needed as well.

    The code, however, should also be considered part of the documentation. Use variables names that make sense. Use table aliases and use those aliases to ensure that people can tell what columns come from what table in multi table queries. Actually, using them in single table queries. You never know when you may have to add a table to a query. Use white space to make the code human readable. Use indenting to help clarify blocks of code. In ORDER BY clauses use column names, not ordinal position to order data. If you have a complex computation, explain it as close to the computation as you can.

    All things that I don't always do. Need to be sure I start doing so I can quit being a hypocrite (Do as I say, not as I do) with regarding to coding. Some people are just better at it than others, either they just find it easy to do or they have been hit with enough pork chops to get the idea. It is a habit that one has to work at until it becomes second nature. I find I tend to comment code that is not as intuitive as other code I write. Should comment it all.

    Code I have been writing at work, I have started adding a nice preamble that I include the name of the proc/function/script/trigger/etc, creation date, author, site (where I was working at the time I wrote it such as ISAF HQ, Bagram AB, Corporate HQ). I try to describe what the code is supposed to accomplish, the requirements the code is supposed to meet. And then I create a Change History log for capturing changes to the code. I have gotten good about the code I put in production, not so much for one offs or code I post on SSC.

  • Kristen-173977

    SSCrazy Eights

    Points: 8419

    Lynn Pettis (9/14/2015)


    -- set @Debug = 1

    set @Debug = 1;

    What in the world does the comment add to this piece of the code.

    Indeed. I find it very confusing because the comment is not clear to me that if I change the code to "set @Debug = 0;" am I suppose to change the comment also?, or is the comment there to remind me what the correct SET value should be?

    :-D:-D:-D:-D:-D

    Anyway, it should be

    set @Debug = 01;

    because it is less keystrokes to remove (or re-add) the 1 than to change it ... at least that's what we do here

    :hehe::hehe::hehe::hehe::hehe:

  • GeorgeCopeland

    SSCertifiable

    Points: 6896

    Lynn Pettis (9/14/2015)


    Describe what the procedure/script/trigger/function/whatever is expected to do, provide a history of changes and way they were made, you may even include some simple test code to run to verify the code works. Just make sure if the code changes that the test code changes as needed as well.

    Change history is easy to get if you use a VCS, and much more accurate than comments in a header.

  • roger.plowman

    SSChampion

    Points: 10173

    Lynn Pettis (9/14/2015)

    I have seen commented code where the comments just got in the way and provided no valuable information beyond what was already there in the code itself. For example:

    -- set @Debug = 1

    set @Debug = 1;

    Yes, I have seen this. What in the world does the comment add to this piece of the code.

    Oh, absolutely. I think a lot of disdain for comments is because people don't understand comments are intended to explain the why of code, not the what. 🙂

    For me (and the reason my code is extremely comment heavy) is I'm explaining my code to the next poor slob that has to understand it. (Which is usually me a year later). Nobody has perfect memory, and as I get older (and have to juggle 3 different languages during a project) I find it immensely helpful to get a guided tutorial of what the hell I was thinking when I wrote the code.

    Was it because I didn't fully understand some whiz-bang technique that was better? Or because T/SQL is a buggy piece of crap that should be shot? Was my understanding of event firing sequences faulty? Or was I compensating for some brain-dead lapse of judgement on MS's part when designing a .Net control?

    In your example I'd want to know *why* the debugger (I'm assuming) was turned on there, not just that it was. What's the performance impact? Are there side-effects of doing so? Was it intended to track down a glitch and is now unneeded?

    Why, not what. 😀

  • Rod at work

    SSC-Dedicated

    Points: 33152

    Wayne West (9/14/2015)


    I'll be honest: I currently do not use a version of VCS. I did back in the Dos days using BRIEF, someone came out with a source control package called Sourcerer's Apprentice that integrated quite nicely. I tried to get VCS at my previous gig but it never happened. At my current gig, I'm more optimistic. I'm going to the Denver SQL Saturday this weekend and doing the pre-con session on DLM and I'm hoping that'll give me the information that I'm looking for to get some tools.

    SQL Saturday in Denver? WOW, I'm interested (I'm in the Albuquerque area), but it is likely too short of notice for me to arrange a place to stay. Still, if I could, I'd be there this weekend.

    Kindest Regards, Rod Connect with me on LinkedIn.

  • Wayne West

    SSC-Insane

    Points: 22586

    Rod at work (9/15/2015)


    Wayne West (9/14/2015)


    I'll be honest: I currently do not use a version of VCS. I did back in the Dos days using BRIEF, someone came out with a source control package called Sourcerer's Apprentice that integrated quite nicely. I tried to get VCS at my previous gig but it never happened. At my current gig, I'm more optimistic. I'm going to the Denver SQL Saturday this weekend and doing the pre-con session on DLM and I'm hoping that'll give me the information that I'm looking for to get some tools.

    SQL Saturday in Denver? WOW, I'm interested (I'm in the Albuquerque area), but it is likely too short of notice for me to arrange a place to stay. Still, if I could, I'd be there this weekend.

    Bummer! I just happened to come across mention of it in an email, and then found that two weeks ago they had one in El Paso. My boss paid for the pre-con for both events and one night of a hotel for El Paso. For Denver I'm staying with a friend who's somewhat close. The funny thing is that Tuesday I'm heading from Denver to Albuquerque for a project launch meeting Wednesday, then back home to Cloudcroft. My boss provided a school car for the trip and they'll be covering my meals and my night in ABQ.

    Definitely something to keep an eye on. Is the Albuquerque chapter ever going to do a Saturday? I think they're having their next meeting this week or next.

    -----
    [font="Arial"]Knowledge is of two kinds. We know a subject ourselves or we know where we can find information upon it. --Samuel Johnson[/font]

  • Steve Jones - SSC Editor

    SSC Guru

    Points: 716562

    pparsons (9/14/2015)


    DVCS all the way! Having started with a "first generation" VCS and coordinating the changes necessary between multiple developers, then progressing to SVN and now to GIT there is no comparison, GIT has it all and is offline 🙂

    Tend to agree. The more I use it, the more I like it.

  • Steve Jones - SSC Editor

    SSC Guru

    Points: 716562

    GeorgeCopeland (9/15/2015)


    Lynn Pettis (9/14/2015)


    Describe what the procedure/script/trigger/function/whatever is expected to do, provide a history of changes and way they were made, you may even include some simple test code to run to verify the code works. Just make sure if the code changes that the test code changes as needed as well.

    Change history is easy to get if you use a VCS, and much more accurate than comments in a header.

    I tend to agree here. I think comments in code are often out of date and more problematic. However the commit (over time) is a good time for the developer to reflect on why they made a change and with some review from other developers, they learn to write useful comments.

    I tend to lean towards the code should explain itself. If it's especially obtuse, give me a result meaning rather than an explanation and I'll decode it.

  • Steve Jones - SSC Editor

    SSC Guru

    Points: 716562

    Rod at work (9/15/2015)


    Wayne West (9/14/2015)


    I'll be honest: I currently do not use a version of VCS. I did back in the Dos days using BRIEF, someone came out with a source control package called Sourcerer's Apprentice that integrated quite nicely. I tried to get VCS at my previous gig but it never happened. At my current gig, I'm more optimistic. I'm going to the Denver SQL Saturday this weekend and doing the pre-con session on DLM and I'm hoping that'll give me the information that I'm looking for to get some tools.

    SQL Saturday in Denver? WOW, I'm interested (I'm in the Albuquerque area), but it is likely too short of notice for me to arrange a place to stay. Still, if I could, I'd be there this weekend.

    Yeah, it's a hike up here. However there are lots of cheap hotels in the Denver, CO Springs, or even Pueblo areas. Love to have you if you want a road trip. Not much happening in Denver this weekend, so hotels aren't full.

  • Rod at work

    SSC-Dedicated

    Points: 33152

    Wayne West (9/15/2015)


    Rod at work (9/15/2015)


    Wayne West (9/14/2015)


    I'll be honest: I currently do not use a version of VCS. I did back in the Dos days using BRIEF, someone came out with a source control package called Sourcerer's Apprentice that integrated quite nicely. I tried to get VCS at my previous gig but it never happened. At my current gig, I'm more optimistic. I'm going to the Denver SQL Saturday this weekend and doing the pre-con session on DLM and I'm hoping that'll give me the information that I'm looking for to get some tools.

    SQL Saturday in Denver? WOW, I'm interested (I'm in the Albuquerque area), but it is likely too short of notice for me to arrange a place to stay. Still, if I could, I'd be there this weekend.

    Bummer! I just happened to come across mention of it in an email, and then found that two weeks ago they had one in El Paso. My boss paid for the pre-con for both events and one night of a hotel for El Paso. For Denver I'm staying with a friend who's somewhat close. The funny thing is that Tuesday I'm heading from Denver to Albuquerque for a project launch meeting Wednesday, then back home to Cloudcroft. My boss provided a school car for the trip and they'll be covering my meals and my night in ABQ.

    Definitely something to keep an eye on. Is the Albuquerque chapter ever going to do a Saturday? I think they're having their next meeting this week or next.

    Yes we (Albuquerque) has had 3 SQL Saturdays at least. I've only attended ours. I'd love to visit another one, just to get some other perspective.

    Kindest Regards, Rod Connect with me on LinkedIn.

  • Gary Varga

    SSC Guru

    Points: 82166

    For me I get to use whatever source code repositories the current client uses...and it varies so much.

    Previous versions of code and the history of it should be in the source code repositories. Only current code (including comments) should be in each version available. There are plenty of tools to check the differences between versions. In fact many are built into source code repository clients.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

Viewing 15 posts - 16 through 30 (of 30 total)

You must be logged in to reply to this topic. Login to reply