netsells / code-standards Goto Github PK

👍 Route::post(), Route::get(), Route::delete() etc
😄 Route::resource()
❤️ $router->post(), $router->get(), $router->delete() etc
🎉 $router->resource()

I prefer ❤️because it's easy to read and allows for autocompletion in IDEs

🎉 "Changed registration validation"
❤️ "Changes registration validation"
👍 "Changing registration validation"

We need to decide if we use brackets in control statements

if(someCondition) {

vs

if someCondition {

With the IoC container, we're not restricted to the order in which we define parameters for controller functions - meaning we can have a function like this

public function update($id, UpdateUserRequest $request, Vehicle $vehicle) { ... }

I feel we should have a defined order for URL Parameters, the request class and resolved IoC classes...

So please comment (or vote on if it's already been posted) your desired order :)

Laravel gives us many ways to pass data to views. Which do we prefer?

Compact 👀

$user = User::first();
$groups = Groups::all();
$permissions = Permissions::all();

return view('groups', compact('user', 'groups', 'permissions'));

With (Array) 🎉

return view('groups')
  ->with([
    'user' => User::first(),
    'groups' => Groups::all(),
    'permissions' => Permission::all(),
  ]);

With (Inline) 🚀

return view('groups')
  ->with('user', User::first())
  ->with('groups', Groups::all())
  ->with('permissions', Permission::all());

We need a spacing format for when using 'logical not operators' within Blade files.

My usual approach is !$variable without a space. But it would be good to get an agreement on whether to include a space or not;

👍 No space !$variable
😄 With space ! $variable

Manually creating validator with Validator::make()

Using the ValidatesRequests trait and validating within Controller.

Creating FormRequest classes to store validation logic before it hits the Controller.

😄$router->get('some-url', 'SomeController@someFunction')->name('some-name');

🎉

$router->get('airport/{airportSlug}', [
    'as' => 'airport.show',
    'uses' => 'AirportController@show',
]);

{!! Form::open() !!}
<input>
{!! Form::close() !!}

vs

{!! Form::open() !!}
    <input>
{!! Form::close() !!}

{{$foo}} vs {{ $foo }}

• JSON responses: snake_case
• Databases names, tables, columns: snake_case
• URL parameters, snake_case: e.g. /user/2/show?include_extra_info=true
• PSR-2 dictates the cases used in PHP code
• GitHub repos: slug-case

Laravel Routes

• Names: slug-case
• URLs: slug-case

We need to agree on a format of spacing before Blade Directive parenthesis.

My usual approach is, any structural directives have no space before the parenthesis, e.g.:

@extends('frontend.layout.app')
@section('body')

But any Control Structures use a space as they would in other programming languages, e.g.:

@if ($foo === $bar)
@foreach ($items as $item)

This is a bit of an inconsistency, but it makes sense. Would like to get an agreement on either:

👍 Always space
😄 Never space
🎉 Space for control structures

Happy path

• Nesting inside a data property (not for nested relations)
• Use snake_case, as we are often exposing database attributes
• Generally we use Fractal's DataArraySerializer

Exceptions

These are defined by Laravel's default error formatting

@craigsansam could you please comment the work you have done in this area and I'll write up

https://eslint.org/docs/rules/arrow-parens

Enforce parenthesis around arguments in arrow functions

👍 - Yay
👎 - Nay

Always use @endsection over @stop

Preferred ordering within a Laravel model:

• constants
• traits
• Laravel specific fields, $table, $guarded, $fillable
• public fields
• protected fields
• private fields
• relations
• scopes
• other methods

https://github.com/netsells/vuejs-developers-api/blob/master/app/Http/Templates/Sections/BannerSection.php

There are multiple ways of defining a route, we need to decide on a convention.

👍 "YPS-6000 - Foo bar commit"
👎 "Foo bar commit"

I'd like to consistently break up Vue components so that they are more readable and each tag is easily distinguishable from the rest.

<template>
   ...
</template>

<script>
   ...
</script>

<style>
   ...
</style>

vs

<template>
   ...
</template>
<script>
   ...
</script>
<style>
   ...
</style>

Add a page with our preferred tech stack. Will make it easier for potential applicants to understand the tech we use.

Worried it might turn some people away, but probably just worth noting on technical tests that we are open to other tech?

Discussed in #481

Continuous

<div
        id="my-div"
        class="my-class"
        v-else
>
    ...children
</div>

vs

<div
    id="my-div"
    class="my-class"
    v-else
>
    ...children
</div>

vs

<div
        id="my-div"
        class="my-class"
        v-else>
    ...children
</div>

vs

<div
    id="my-div"
    class="my-class"
    v-else>
    ...children
</div>