Developer Area/Developer Meetings/93

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
• Next step towards PHP 8.1: Introduce a project-wide linter (re-think our standards and adapt to more modern PHP 8 standards)
  • 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. Difficult to update and manage as it's hard-coded
    3. Only covers a small subset of rules
    4. These set of rules are managed by us, and we don't have time to look for each rule ourselves.
  • Why should we have a linting tool?
    1. Consistent code and coding practices and becoming more PHP 8 compliant.
    2. Automate some code-review, so the dev can use time better by focusing on the important logic of patches
    3. Never argue about syntax ever again when the standards are computed!
    4. Easily change, update, and adapt the rules within the project consistently with a tool that pulls in modern coding standards for us.
    5. Give new developers an easier time picking things up with a computed style guide and start pushing code faster.
    6. We can go at our own speed. Start with warnings first, and slowly turn the rules into errors. Errors prevent pushing, warnings only suggest.
    7. Eventually, our CI can enforce/warn us of issues where we can still push the code and disallow merging, i.e. on GitLab
    8. 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?
    • 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
  • 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 including university
    • https://firefox-source-docs.mozilla.org/code-quality/coding-style/coding_style_cpp.html Mozilla Firefox's standards
  • At Catalyst
    • 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
    • Going forwards, there will be minimal changes in code.
    • They use for JS: Prettier, where they can adjust the rules in a prettier.rc/.json
    • 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.
    • Bob: We should have it that the tool formats the code, so we can diff before pushing changes.
  • 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 '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.

New items

General items

• Any other business
• Next meeting and chair