Studies have shown that reading someone else's code can be both stressful and time consuming. Developers that pick up unfamiliar code find themselves spending much more time comprehending the code than with more familiar projects. I think this might be one of the reasons that so many developers want to build things themselves from scratch, or in least build new things in their team. They find their own code easier to understand.

This might be less of an issue with SQL code, which is often more straightforward for simple queries, but I  do find that complex queries can be confusing to many developers if they didn't write the code. This can especially true when another developer has used some rather uncommon trick. I'm also sure that plenty of people will cut and paste solutions, from places like SQLServerCentral, without understanding how the code works, but even decoding the answer to a question you've asked can be hard, even if another poster tries to explain how the code works. Hopefully most developers make an effort rather than coding a poorer solution or deploying code they don't understand, but I'm sure some don't when facing their own pressures to get work done.

With staff turnover and the need for developers to work on multiple projects, time spent interpreting code can be a drain on the efficiency of all developers. In addition, since individuals often find code easier to read in certain formats, tools like SQL Prompt can help, but there are plenty of easy ways to keep your codebase readable for staff. Dr. Greg Low has written a nice post on standards, which I think outlines some of the things I like to implement in a team. Having a known way to structure our code can help us communicate intuitively in a group, rather than require extra communication.

Actually, I don't care what standards exist in a company. I don't have strong feelings about any particular way to structure code. I prefer spaces, but if we decide on tabs, I think that's fine. I'll work within the framework we've built. What I do think is very important is that you have some standards. They don't have to be perfect or exhaustive, but they do need to be followed.

If you don't have standards, I suggest you start creating them. Add them as needed, when a developer finds a reason to make a decision, get consensus from the rest of the group and document the standard. Like other things in DevOps software development, we can grow these over time as we need them.