Home Forums SQLServerCentral.com Editorials Should your Source Control System understand your code? RE: Should your Source Control System understand your code?

  • Why would source control need to understand the code? That is the responsibility of the Programmer/s.

    The advancements being made in languages is making entry into the Computation Sciences workforce much easier. As a result, there is a plethora of unqualified individuals coming into the field. By unqualified I mean individuals who:

    -Have bad coding practices

    -Lack discipline that is required to be a programmer

    -Refuse to/Do not follow standards and design. Their errors usually go unchecked, even with code review, because management will not take the time to make them correct things if the code works. As a result the entire department deals with the fallout.

    -Lack the fundamentals(knowledge of alternate number systems, ADT programming, SET Theory etc.)

    -Think commenting is a waste of time

    If a shop is scared of Branching and Merging because it impedes their ability to deliver rapidly then that tells me a few things.

    1) They lack discipline

    2) They lack the ability to put policies and procedures in place to support B&M as a result of 1.

    3) They lack the backing from management to enforce 2 because of 1

    From where I sit it takes much more time and is much riskier to use flags in code instead of B&M(It will also make the thought of merging scarier because of all the silly extra code). If a shop is so immature that it does this, I do not see how they can support concurrent projects on overlapping code without chaos.

    Having said that I would like to see source control allow for a programmer to lock a version of code in one layer to a version of code to another. I.E. Lock a version of a stored procedure to a version of a Service that uses,

    P.S. What would Automatic Testing accomplish that Unit Tests can't?