Lim Kha Shing limkhashing

List of dependabot branches

dependabot/actions/*
dependabot/github_actions/actions/*
dependabot/github_actions/github/*
dependabot/github_actions/gradle/*
dependabot/gradle/*

Here are some helpful tips for your Codelive Interview:

Coding, Data Structures, Algorithms In this round, we aim to assess your fundamental understanding of Programming, Data Structures, Algorithms, and your aptitude for problem-solving. We also evaluate your ability to comprehend problems, communicate your thought processes, implement solutions in code, and optimize them.

What you can expect

Solve coding problems that will assess your knowledge of data structures and algorithms.
Discuss your approach to problem solving and demonstrate your professional understanding of the principles of software engineering.
Display your knowledge of platform/language specific basics and fundamentals.

Keeping our libraries up-to-date

Context

We use many third-party libraries in order for us to build a feature-rich app. To scale up to the needs of our consumers, we’ve adopted ways to efficiently deliver our services. So frequently updating our library versions is important for our app.

As of DD/MM/YYYY, we have N+ libraries that we need to maintain. This includes a mixture of Core AndroidX libraries, UI libraries, Networks libraries, Payments libraries, Google libraries, Firebase libraries, Trackers libraries, Unit Testing libraries etc

Why do we do this?

Practical skills that you should learn

Let's be honest, the program or code that you wrote can also be scribbled (As long as can it can do the work right?). But this makes it harder for the new person that comes in and reads your code, as they don't have the context of what and why you wrote such a way. And this is even worse when comes to debugging if issues rise up.

And generally, codes are read more often than written, and existing features are maintained more often than developing a new feature or product. So, If you want to write well or be easy to read, you have to spend a lot of effort to learn writing skills. But quality codes come with big advantages, such as:

Improved the workflow efficiency
Increased the testability of the app
Building a professional and structured way of writing code

What you should pay attention to when creating Pull Requests

Creating Pull Requests

Clear and Descriptive Title: The title should succinctly describe the purpose and scope of the PR. It should give reviewers a good idea of what the PR is about. Our general format when creating a PR title:
1. [TICKET_NUMBER] [TYPE (OPTIONAL)] TITLE FOR THE PULL REQUEST
Detailed Description: Provide a comprehensive description of the changes made in the PR. Explain why these changes are necessary, how they address specific issues or requirements, and any potential side effects.
Link to Issue or Feature: If your PR is related to a specific issue or feature request, link to it in the description. This helps maintain traceability and context.
Scope: Keep PRs focused on a single task or a small, logically related set of changes. Large, monolithic PRs can be difficult to review and merge.
Code Quality: Ensure that your code adheres to the coding standards and style guidelines of the

GitHub Labels

This document serves as a guide for issue label tagging when raising a pull request.

As part of our best practices across our GitHub repositories, and also to best align with iOS, we have decided to include more labels as part of the PR process for better clarity and sanity.

A single PR can contain multiple labels depending on the issue and how u arrange them.

Note: Avoid adding labels for the sole purpose of soliciting attention, especially priority-based labels, maybe some issues are better-raised label-less... so choose wisely.

Kotlin clean code and best practices

Clean Code Rules

Our main aim is to have a clean code, avoid common silly mistakes and reduce the load on engineers during PR reviews. This is a team effort and If anyone has something that’s generally applicable, let’s talk and decide whether it should be baked into our style guide— so everyone can benefit from it

The bad code creates a lot of distractions. It causes developers to waste time and energy navigating through functions, classes, and files, and pouring over code trying to understand it.

Working on a project where developers care about clean code makes it easy to understand its virtues; the developer can read the code from top to bottom in one go and clearly understand what it does. It makes code manageable and maintainable in the long term, isolating changes and increasing the efficiency of the team.

Onboarding for Android

Please make sure that you read and did everything here Put your company onboarding template when you onboarding to XXX

Access checklist

Staging Firebase Console
Production Firebase Console
Google Play Console
Huawei App Gallery

The Right Way to Document Your Code

Readable code means we just read the code like a book, without process alot of logic behind our brain.
- And rather understand rightaway what a piece of code does
Boolean expression should always keep in positive expression to minimize cognitive load
Comment the why, not the what.
- Don't add comment explaining what the code did, all you're doing is adding noise to the code
- Comments should be used only to explain the intent behind code that cannot be refactored to explain itself.

Mostly used for providing additional context, i.e. answering the WHY not the WHAT.

	class MainActivity : ComponentActivity() {
	override fun onCreate(savedInstanceState: Bundle?) {
	super.onCreate(savedInstanceState)
	setContent {
	SwipeToDeleteComposeTheme {
	// A surface container using the 'background' color from the theme
	Surface(
	modifier = Modifier.fillMaxSize(),
	color = MaterialTheme.colorScheme.background
	) {