Actions

Developer Area/Developer Meetings/93: Difference between revisions

From Mahara Wiki

< Developer Area‎ | Developer Meetings
No edit summary
Line 12: Line 12:
*Update coding and code review guidelines to add words around security
*Update coding and code review guidelines to add words around security
*PHP 8.1 progress
*PHP 8.1 progress
*Next step towards PHP 8.1: Introduce a project-wide linter (re-think our standards and adapt to more modern PHP 8 standards)
*Idea to progress towards PHP 8.1: Introduce a project-wide linter
**What we currently have: <code>make minaccept</code>  
**What we currently have: <code>make minaccept</code>  
**#Written in 2010  at the time of ''PHP 5.3'' standards (12 years ago, which matched that standards at the time of it was written)
**#Written in 2010  at the time of ''PHP 5.3'' standards (12 years ago, which matched that standards at the time of it was written)
**#Difficult to update and manage as it's hard-coded
**#Unmanaged and difficult to update and manage as it's hard-coded, covering a small subset of rules
**#Only covers a small subset of rules
**How does a linting tool help us?
**#These set of rules are managed by us, and we don't have time to look for each rule ourselves.
**# Less time spent on syntax, more on implementing and pushing solutions (towards PHP 8 compliance).
**Why should we have a linting tool?
**# Easily to change, update, and adapt the rules within the project as we need and in our speed.
**# Consistent code and coding practices and becoming more PHP 8 compliant.
**# Eventually, CI/CD can warn us of issues of new code we push the code before merging, i.e. on GitLab
**# Automate some code-review, so the dev can use time better by focusing on the important logic of patches
**# With a standardised syntax, the core team can more easily work with community patches and get them in faster.
**# Never argue about syntax ever again when the standards are computed!
**# Easily change, update, and adapt the rules within the project consistently with a tool that pulls in modern coding standards for us.
**# Give new developers an easier time picking things up with a computed style guide and start pushing code faster.
**# We can go at our own speed. Start with warnings first, and slowly turn the rules into errors. Errors prevent pushing, warnings only suggest.
**# Eventually, our CI can enforce/warn us of issues where we can still push the code and disallow merging, i.e. on GitLab
**# Crucial that open source project standardise syntax so core devs can save time when community members will have different coding styles.
**What is a linter and formatter?
**What is a linter and formatter?
***A linter is a static analysis tool that can show us area of bad coding practice.
***A linter is a static analysis tool that can show us area of bad coding practice.
Line 33: Line 27:
*** We can change the strictness, warnings vs. errors.
*** We can change the strictness, warnings vs. errors.
*** Formatters provide syntax checking and updates code
*** Formatters provide syntax checking and updates code
**At Catalyst
**How does it help other teams at Catalyst?
*** The frontend team use Prettier formatter – a set of rules to follow
*** The frontend team use Prettier formatter – a set of rules to follow
*** The code was only ever all changed just once after deciding on the rules
*** Fix once, get the benefits going forwards with minimal changes
*** Going forwards, there will be minimal changes in code.
*** By using Prettier for JavaScript, they can adjust the rules in a prettier.rc/.json for each project.
*** They use for JS: Prettier, where they can adjust the rules in a prettier.rc/.json
*** The frontend team agreed to use Airbnb style guide to help  use best practices, but there are many others to choose from.
*** There are many style guides. The frontend team agreed to use Airbnb style guide to help  use best practices.
*** Have formatters to automatically execute upon saving a file.
*** Tools shouldn't be blockers, they need to help us.
*** Look into prettier for formatter, ESLint for linter. When starting on ESLint, it asks you for the rules you like.
*** Look into prettier for formatter, ESLint for linter. When starting on ESLint, it asks you for the rules you like.
*** Bob: We should have it that the tool formats the code, so we can diff before pushing changes.
*** We could have it as a tool that formats the code, so we can diff before pushing change
** Cons of linters/formatters
*** What if it changes logic? They shouldn't, but we can choose our speed by setting all rules warnings at the start, and fix one rule at a time.
*** Even though it's looks different at the start, over time it will become familiar.
*** Everything was ''<nowiki/>'new''' at a some point.
*** We don't like things secretly changing our code in the background. Don't use a formatter, just start with a linter so that you can solve the issues.
** Examples of backend languages moving forward with syntax, specifically if/else cuddling
***https://www.oracle.com/java/technologies/javase/codeconventions-programmingpractices.html - Java
***https://www.php.net/manual/en/control-structures.elseif.php - the official PHP website cuddles their if/else ifs
***https://www.php-fig.org/psr/psr-12/ - PHP PSR12 standards
***https://www.perltutorial.org/perl-if/ - Perl
***https://www.w3schools.com/php/php_if_else.asp - Standards taught today for students/learners
***https://firefox-source-docs.mozilla.org/code-quality/coding-style/coding_style_cpp.html Mozilla Firefox's standards
New items
New items


Revision as of 15:32, 18 Ocak 2023

Agenda for the 93rd Mahara developer meeting on Tuesday, 24 January 2023 at 23:00 UTC

We will meet online using Big Blue Button (A Catalyst staff member will initiate the call).

Our #Mahara channel on Matrix will be our backup in case there are problems with the web conferencing tool and we'll need to chat to resolve it. You can connect to our Matrix channel also using the #mahara channel on Freenode IRC.

  • Chair: Doris Tam
  • Minute taker: Gold

Chair and minute taker duties explained

Agenda

Items from previous meetings

  • Change to makefile to add some basic security checks
  • Update coding and code review guidelines to add words around security
  • PHP 8.1 progress
  • Idea to progress towards PHP 8.1: Introduce a project-wide linter
    • What we currently have: make minaccept
      1. Written in 2010 at the time of PHP 5.3 standards (12 years ago, which matched that standards at the time of it was written)
      2. Unmanaged and difficult to update and manage as it's hard-coded, covering a small subset of rules
    • How does a linting tool help us?
      1. Less time spent on syntax, more on implementing and pushing solutions (towards PHP 8 compliance).
      2. Easily to change, update, and adapt the rules within the project as we need and in our speed.
      3. Eventually, CI/CD can warn us of issues of new code we push the code before merging, i.e. on GitLab
      4. With a standardised syntax, the core team can more easily work with community patches and get them in faster.
    • What is a linter and formatter?
      • A linter is a static analysis tool that can show us area of bad coding practice.
      • A static analysis tool to find weak spots in the code, highlighting issues
      • where rules are configurable
      • We can change the strictness, warnings vs. errors.
      • Formatters provide syntax checking and updates code
    • How does it help other teams at Catalyst?
      • The frontend team use Prettier formatter – a set of rules to follow
      • Fix once, get the benefits going forwards with minimal changes
      • By using Prettier for JavaScript, they can adjust the rules in a prettier.rc/.json for each project.
      • The frontend team agreed to use Airbnb style guide to help use best practices, but there are many others to choose from.
      • Look into prettier for formatter, ESLint for linter. When starting on ESLint, it asks you for the rules you like.
      • We could have it as a tool that formats the code, so we can diff before pushing change

New items

General items

  • Any other business
  • Next meeting and chair
Retrieved from ‘https://wiki.mahara.org/index.php?title=Developer_Area/Developer_Meetings/93&oldid=13532’