marcia.j.wilson (5/7/2015)
Eric M Russell (2/10/2012)
Another scenario is where the developer includes un-needed table joins and returns additional columns that are never referenced by the application or reporting tool. I've even seen procedures that query an interim result into a temp table, which is then never used. This is often the result of a developer wrting a new stored procedure by copy/pasting from an existing stored procedure, and then failing to remove those table joins, columns, and code that arn't needed.Copy/paste is a great way to avoid unnecessary work and I use it often. But it does require someone smart enough to figure out what's really needed in the new code and what should be dropped. Unfortunately, some people are too lazy to do that.
Another thing that irks me is when someone copies/pastes from code I've created, including header comments, and then leaves my name as the creator on their code. Especially when it's code I would never have created.
I see this happen when a developer is maintaining the heavy code of someone long gone. The process is usually obscure and a minor tweak to the code may be needed. All else is left in order to not break any corner cases since as a newcomer you dont want to make business decisions on something that was left in place unless you know everything involved for a fact (100 %) . This other option requires a commitment to time and happens when a re-engineering is called for. In those cases I prefer to get user requirements, and start from scratch. That would be more efficient and I can also leave a proper manual documenting the build. BTW - Joining on other tables without returning columns from the other table is a valid option for the purpose of filtration.
----------------------------------------------------