akash-network/website-5-archive

Code Inspection and Cleaning

Closed this issue · 1 comments

aktdenis commented

Description

@HoomanHQ (Discord user:Boldpanther) observed that implementation is not done in systematic manner following best or even good practices.

Note* This is a separated issue from a list of issues in issue 209 (akash-network/website#209)

Steps describing how to reproduce the issue.

258109590-9765dd8b-18b0-41b2-aa91-836d2726c41a.mp4

1 . class does not exists for the "clicked_header"

Explanation: On line 68, the “clicked_header” is added and removed but when we search for the class in the project there is no styling defined for that class.
Issue: Unused codes are left uncleaned.
Could confuse other developers and the debug process could be time consuming.
Solution: We will find out this kind of unused code and remove them.

  1. inline styles are overriding the class itself

Explanation: There are some inline styling along with class styles which could be avoided.
For example on line 227, 229 and 232, they have the same styles with different class names along with 3 inline styles (same styles) added respectively. Similar issues can be seen on line 228 and 231.
This process makes the styling codes scattered.
Issue: The inline style overrides the class styles (for example class “featured_header”) and it could be time consuming to notice and makes the code unorganized.
Solution: “group-1_header”, “group-2_header” and “group-3_header” can be written as one class with unique IDs if anything specific needs to be done to the elements, this way the codes will stay clean and easy to understand.

  1. !important is overused

Explanation: For example on line 14 and 21, there are !important used which might create confusion to future developers if they try to update the class.
Issue: This could cause problems for a developer in future if they try to make any changes with classes and media query. This could be avoided and handled in a better way.
Solution: It would be good if we could write styles by avoiding !important, this way the code will be changeable and won’t cause override issues.

  1. media query is not using best practices (HoomanHQ please add details to the issue)
    Explanation: There is no consistency in the media query breakpoints. If we take a look at the left side of the screenshot there are different breakpoints and some have decimal points.
    Issue: This could cause confusion for a developer in future if they have to work with responsive design and breakpoints.
    Solution: It will be good if we use and maintain standard breakpoints guidelines (i.e official bootstrap breakpoints) for different screen sizes.

  2. code repetition // no example provided (HoomanHQ please add details to the issue)
    In some components, code is used separately for larger & smaller devices. For example, on line 128 (large device) and 178 (small device), in simple sections like these the codes could be minimized and written using fewer lines of code.

  3. avoid "local" classes defined for specific elements (HoomanHQ please add details to the issue)

Explanation: There are classes that are defined which could cause confusion in future for developers. For example, in the global.scss file there are tags from h1 to h6 with custom margin.
Issue: This could cause confusion and override issues for a developer in future if they have to work with new design for a specific tag as margin could differ based on design and font sizes.
For example on line 178 of index.html, the h2 tag has a h4 class even though in the global.scss has the same styling for all of them.
Solution: We will fix the issues like line 178 and fix them by using styles for related classes.

  1. Additionally, similar to the guidelines provided for the designers, proper commenting for codes and documentation will help future developers to understand how everything has been done here.
    For example global css and variable for stylings are used but without documentation, which makes it difficult for developers to understand the use or cause of variables and could lead the variable to be not utilized properly.
    Proper commenting: In future it will be helpful for the developers which code belongs to which component.

Why is it important and what impact will it have on akash?

As an open-source project where multiple developers could be participating, providing an overall clean and well documented code structure will be beneficial for the future of the project and scalability. We will be able to achieve those by solving the issues mentioned above.

aktdenis commented

Additional info from @HoomanHQ:

During this phase, our web development experts dedicated 10-15 hours to inspecting and understanding akash website's existing code base. We observed that implementation is not done in systematic manner following best or even good practices.

Code Inspection and Understanding: 10-15 hours
Code Cleaning and Optimization: 25-30 hours
Total Estimated Time: 35-40 hours