Chapters

27 Chapters | 16:38:22 |

01

Back to the Basics (Symfony local Web Server)

31:36
02

Knowing your State Machines

45:03
03

Behat Best Practices with Symfony

43:32
04

File Storage for Modern PHP Applications

39:49
05

Symfony Messenger: 6 months already and more to come

34:02
06

Going crazy with Varnish: Caching pages of logged in users

44:26
07

Changing PHP

34:14
08

Using Symfony Forms with Rich Domain Models

40:03
09

One year diversity initiative

37:11
10

How Static PHP Analyzer Changed the way I Look at Code

34:19
11

Building Global Web Apps with Multi-region Hosting

40:20
12

Building Apps for Immutable Servers

34:52
13

Bulletproof MongoDB

43:33
14

Leverage the power of Symfony components within ApiPlatform

27:45
15

The Patterns Behind Doctrine

37:39
16

When Testing Makes No Sense

36:55
17

Microservices Gone Wrong

39:20
18

Security: Handling User Access with Symfony the Right Way

29:41
19

Webpack Encore: Tips, Tricks, Questions & Best Practices

50:45
20

My first year with event sourcing (in Symfony)

41:25
21

Symfony 4 Internals

41:48
22

What’s a Typical Symfony 4.2 Application Like?

37:38
23

Modern Application Built from Scratch: API Platform FTW

34:25
24

Integrate (Vue)JS Components in a Symfony App, add E2E Tests with Panther

41:44
25

Profiling your Symfony Application

42:50
26

A Year of Symfony

22:17
27

Magic

11:10

This course is archived!

> Symfony Conferences > SymfonyCon 2018 Lisbon Conference Videos

Buy Access to Course

10.

How Static PHP Analyzer Changed the way I Look at Code

|

Autoplay

Previous Chapter

Next Chapter

Script
Comments

Login or register to check out the script

5 Comments

Sort By

Login or Register to join the conversation

Lijana Z. 6 years ago

I like multiple return points. No need to store in variable. Less variables - more simple for me it looks.

|

Victor SFCASTS Lijana Z. 6 years ago

Hey Coder,

Agree, code looks simpler and clearer with fast returns, I like them too. And IIRC it's even a PSR standard... or I might be wrong, but it's definitely a good practice I think :)

Cheers!

|

Lijana Z. 6 years ago

she makes me sleepy. This might be good when you have insomnia at night :)

|

Lijana Z. 6 years ago

About not needign comment code because its in version control. No - its not as easy, its easier to uncomment than to search in git what I have removed.

|

Victor SFCASTS Lijana Z. 6 years ago

Hey Coder,

Thank you for sharing your point of view! Well, it might depend. But when you use good tools like Git and host your code on GitHub, and use feature-branch development - most of the time it's very easy to find the code that you removed. But agree, in some cases when you just need to temporarily comment out a few things to try how it works and most probably you might want to revert it after the try - it's easier to use comments :) But when we're talking about a feature that you might want to return in a few years, or maybe even never - it may have sense to remove it at all and in case you would need it in the future - get it back from the Git. So, mostly it depends.

Cheers!

|

Previous Chapter

Next Chapter