SQL Server Development worst practices

So far these are the worst practices that I have experienced till now in database development. there are many standards and guidelines that the developers should follow , but till now I came across these and going forward I will update the same with my findings.

1. create view on top of another view : mostly happens on product related databases where the table names are not meaningful. for e.g.:. remedy database has the table names with numbers , when a developer creates a view on this table with a meaningful name for a particular requirement , another developer starts creating his view based on the first view and so on and it will end up with having n no.of views , so while troubleshooting the performance problems or during any change request , its very difficult to track and implementing the changes as modifying one view might cause the other dependent views to fail and more over controlling  the permissions on the views will be bit difficult.
2. Improper indexing :
   • mostly happens when the schema released to production from designer tools like Erwin where sometimes it creates non-clustered index on the primary key.
   • creating indexes to quick fix a performance issue for one transaction with out analyzing the impact on other transactions. on a highly OLTP table , this takes lot of I/O to update the corresponding records in all the index pages. In the context of business if registering a new user is so important to business rather than searching a particular user information and if the time taken to register one user takes 2 minutes which effects the revenue to the business then there is no point in giving preference to search queries through heavy indexing.
3. Long Transactions
• mostly happens when the transactions begins and waiting for the user to commit. while design the application , developer need to take care to avoid long running transactions.
4. Isolation Levels
• mostly happens when the developer doesn't pay attention to the problems with blocking , locking etc. for reporting queries most of the developers wont use the least transaction levels though the business permits to use , so for e.g.:. while executing a select statement to produce the report , if its okay to have the reporting data to include dirty reads (most cases) then its better to use least isolation mode.
5. No standards checklists
• most of the developers will not validate their code with the DBA before releasing to the production. I would say , they should validate before designing the code but since its impractical to hold the DBA all the time during development , there must be a standard checklist in place before developing and should be reviewed periodically with the DBA.
6. starts coding procedure with out logical design
• for simple procedure , its not required but for a large complex stored procedure , developers must design the flow of the logic including the way how they are interacting with the datasets, this helps the developers to create the most efficient procedure in terms of performance and to meet the business requirements.
7. choosing improper objects
• choosing table variable instead temp table , vice versa
• choosing physical temp table instead #table
• choosing cursors by default with out looking alternatives
• etc...
8. not capturing system requirements (performance baselines)
• developers must have clear understanding on how much time the procedure is going to take to complete when released to the production , this will helps the developer to fine tune the procedure at the design level itself.
9. Triggers :
• mostly happens when the front-end developer trying to load everything to backend , I have seen this during last minute changes before deployment with out thinking on the impact of the trigger on database in terms of performance and managing triggers.