This isn't so much an indictment on your place of employment as it is testament of the industry as a whole. Most places where you will go will have questionable code to some degree or another. Some places will be better than others for quality, readability, & maintainability as each means different things to different people, & recognize that making schedules usually is much more important. I have also been part of companies who try to legislate every possible aspect of the development cycle, & it is a wonder that anything ever got done. So realize that everything has to be balanced.

Inserting use of static analysis tools into the development process only makes sense if they are integrated early in initial development. I have been part of companies who appeased some vice-president by forcing development staffs to enforce that all code pass through lint(1) without warnings long after the code had been deployed in the field. This meant that portions of the staff had to allocated just to go back through the code correcting thousands of C casts & initializations for months. Given that the code had been in the field at that point for years, the benefit of such activity had negligible value. In fact, it required more hours to be spent by a larger portion of the staff checking through trivial syntax changes to ensure that code correctness wasn't introducing more bugs. Was this place particularly bad? No, not at all. In fact, the code coming from my group was pretty good from the beginning. Quality practices have to balanced with the value they provide.