Clean Code

This was a really good distillation of the themes from the Clean Code book along with some of Peters own thoughts on how to make our code bases more readable and maintainable. Covered a lot in 20 minutes, but didn't feel rushed.

There were a couple of points in the talk where we were told not to use something (e.g. switch statement) a brief explanation why and what the alternatives are would have been nice, but appreciate the time constraints on the shorter format.

Really didn't feel like a first time speaker and all in all a good talk, thank you Peter.

It was a great first talk, Peter had great command of the room and even though the dense content of the talk the slides and the talk were clear and understandable.

Your talk was a good reminder of a lot of concepts that I was aware of, but have perhaps let slide!

One piece of feedback I would have is that you mentioned that PSR-1 came first followed by PSR-2. The reality is that they were originally the same proposal but were intentionally split. PSR-1 was more serious structural guidelines that influenced interoperability and PSR-2 take it or leave it guide to help those who contributed to multiple projects. Phil Sturgeon explains this well - I've heard him mention it on a couple of podcasts and talks about the history of the FIG group.

I have a personal opinion that one or two of the suggested guidelines are good practices that we should aim for - but that there are many scenarios where adhering to them isn't ideal. Having said that, I've found before that had other parts of my code been designed properly - it wouldn't have be common sense to violate such guidelines in others. I'll reserve judgement until I've done some of the background reading!

I think Michael Cullum's point was also worth noting (so I'll repeat it here). If you're creating a public API you need to account for the flexibility to add features without breaking backwards compatibility. For example, if you need to add a method to an interface, you're straight away looking at a major version change - because other libraries could have built against the interface as it stands in the current version. If you give this talk again, it might be worth mentioning how certain scenarios and business demands take precedence over style and structure best practices.

5*'s anyway because with limited time and such a huge topic I thought you did very well - it would be impossible to give a thorough background on code style best practices on a lecture course, never mind a 20 minute presentation.

I also thought you spoke very well and should definitely look into doing more speaking!

Peter talks very clearly and at a pace which is neither too fast nor too slow, he was easy to listen to.

The talk was a nice introduction to some of the clean code concepts. There were a couple of occasions where I felt some code samples were described as not very good but there could have been an explanation to back up why that was - however in other cases this was done very well.

I look forward to seeing Peter speak in the future.