question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Standardize code "style" across packages

See original GitHub issue

We are using a variety of code styles (var naming, function declaration, modularization) across our packages. We should take stock of the different styles and as a team choose a general code style and update our packages to match.

This will be three phases:

  1. Go through code (ts/tsx files in particular) and take not of the different styles we use
    • variable naming conventions (eg camelCase vs underscore)
    • how we declare functions (functionName() {} vs functionName = () => {})
    • how we break up and spread out code across files in a package
  2. Meet as a team and decide which methodology we want to use for each styling
  3. Go through the code and update to match the chosen styling.

Issue Analytics

  • State:closed
  • Created 4 years ago
  • Comments:5 (5 by maintainers)

github_iconTop GitHub Comments

1reaction
ajbozarthcommented, Feb 26, 2020

Once #296 is merged we can start work on this

0reactions
ajbozarthcommented, Apr 3, 2020

Update from my inital work and discussion in scrum today:

  • Based on jupyterlab we will not lint on camelCase and will just do our best to always use it since there are jupyterlab vars we utilize that use underscore vars.
  • Our current code uses “function expressions” 99% of the time already and so I will be adding that check to the lint and fixing the few deviations. This does not address the “apparent” issue though, as detailed below.
  • Function expressions can be written a few ways:
    • static myfunctionName(): void { } will make a function can be called as UtilClass. myfunctionName() by importing the containing UtilClass
    • myfunctionName(): void { } which can be called within a class with this.myfunctionName()
    • private myfunctionName = (): void => { } which can be called locally as myfunctionName()

All of these are valid and have their use cases despite looking different, as such we will allow them to all be used.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Code style options and code cleanup - Visual Studio (Windows)
First, configure which code styles you want to apply (in one of two profiles) in the Configure Code Cleanup dialog box. To open...
Read more >
Code Style and Formatting - The Turing Way
A coding style is a set of conventions on how to format code. For instance, what do you call your variables? Do you...
Read more >
Tools for Consistent JavaScript Code Style - Bits and Pieces
Reusing code, in and across repositories, is essential for standardized and clear code. Exploring shared React components in Bit.dev. Prettier.
Read more >
Standardizing the code style in a Node.js project - Headsigned
Having a common style is valuable both to the project and the team. ESLint, Prettier and EditorConfig make this process fully automatic.
Read more >
How to configure and enforce coding standard rules - Devbridge
EditorConfig is a code styling configuration that gets rid of simple mistakes such as different indentation type usages.
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found