Lint_hard: All The Lints Except Where They Clash

Lint Hard

The objective of lint_hard is to reduced the accumulation of technical debt by improving code quality and consistency whilst turning runtime errors into compile time errors.

Lint Hard employs strong mode type saftey to improve code clarity and remove 'ambiguity of intent' found in typeless or softly typed code.

Lint Hard turns many of the common runtime errors into compile time errors. The rule of thumb is that it is 10 times harder to fix a runtime error than a compiler error. Lint Hard will save you time and frustration.

Using Lint Hard will require you to do a little more work as you code but will significantly reduce runtime errors saving far more time than you will spend cleaning your lints. The dart fix command also automates fixing many of the most common lints reducing the workload.

Lint Hard forces you to use consistent standards across your code base which makes it easier for other developers to read your code. It will also help when you come back to your code in 12 months time.

drop in replacement

You can use Lint Hard as a drop in replacement for your existing lint package (pedantic, lints, flutter_lints ...).

what lints are included

Lint Hard includes every non-clashing dart lint and enables strong mode type checks.

strong-mode:
    implicit-casts: false
    implicit-dynamic: false

You can see the full set of lints in the analysis_options.yaml file.

other improvements

The Lint Hard project also offers the following advice to help you improve the overall quality of your project.

Or you can just jump to the bottom of this page to install Lint Hard.

dart format

We strongly recommend that you use dart format to format your code. Whilst personally I don't like some of the formatting decisions imposed by dart format, consistency is more important. Don't fight this one. Just run dart format with no options. You will get used to the format and it makes sharing code with other developers easier. Using dart format will also make it easier for you to read other developer's code as dart format is almost universally used in the Dart community.

dart format will improve your commit history as it won't be fouled with format differences. This is particularly important in a team project but will render dividends even if you work alone.

Use an IDE like vs-code that automatically formats your code each time you save it.

Only commit code that has been formatted.

a word to JavaScript developers

If you are coming from the JavaScript world, enforcing type declarations may initially feel burdensome but you will quickly see that it allows you to develop faster and release quality code sooner.

avoid dynamic and Object types

For the most part you should never use the dynamic type and rarely use the Object type.

There are exceptions to these rules such as when parsing json dart. But you should always try to use an actual type. dynamic and Object should be last resorts.

Adjustements for package developers

If you are building a dart package then you should be adding documentation to all of your public methods. To ensure you do this consistently add the following to you analysis_options.yaml:

linter: rules: public_member_api_docs : true

Use nnbd

This one probably doesn't need to be said, but just in case...

If you haven't already moved your project to Not Null by Default (nnbd) now is the time to do it. We do recommend applying Lint Hard to your project first and then doing the nnbd conversion. A cleaner code base will help the nnbd migration tool.

Now you have nnbd enabled, try to minimize the use of '?' operator. Use non-nullable types as your default. Only use a nullable type if the variable really needs to be nullable.

Use techniques such as default values and (carefully) the late keyword.

installing Lint Hard

To install lint_hard into your app or package:

Check in any existing code changes.

run dart format

 dart format

Check in the formatted code

If you already use dart format you can skip this step. If you don't currently use dart format this step will make it easier to diff your lint changes as they won't be mingled with format changes.

In a terminal, located at the root of your package, run this command:

dart pub add --dev lint_hard

Create or modify the analysis_options.yaml file in the root of your project:

include: package:lint_hard/all.yaml

Remove your existing linter

If you are using another linter such as lints, pedantic, flutter_lints etc. now is the time to remove it. Your existing lint package should be listed in the dev_dependencies section of your projects pubspec.yaml.

If you have been using the pedantic package it may be in the dependencies section. Remove it also.

run dart fix

The dart fix command will apply a number of automated fixes based on the lint_hard settings.

Run:

 dart fix --apply

Re-run dart fix until it reports 'Nothing to fix!'

run dart format

Finally run dart format over your code. Ideally you should be using an IDE that automatically formats your code whenever you save.

avoid_print for Flutter users

Flutter users may want to add the following to your project's analysis_options.yaml

 linter:
   rules:
     avoid_print: true  

customizing the predefined lint sets

You can customize the predefined lint set, both to disable a lint or to add additional lints. For details see [customizing static analysis].

Use this package as a library

Depend on it

Run this command:

With Dart:

 $ dart pub add lint_hard

With Flutter:

 $ flutter pub add lint_hard

This will add a line like this to your package's pubspec.yaml (and run an implicit dart pub get):

dependencies:
  lint_hard: ^2.1.0

Alternatively, your editor might support dart pub get or flutter pub get. Check the docs for your editor to learn more.

Download Details:

Author: Onepub-dev
Source Code: https://github.com/onepub-dev/lint_hard 
License: BSD-3-Clause license

#flutter #dart #lint

What is GEEK

Buddha Community

Lint_hard: All The Lints Except Where They Clash

Lint Hard

The objective of lint_hard is to reduced the accumulation of technical debt by improving code quality and consistency whilst turning runtime errors into compile time errors.

Lint Hard employs strong mode type saftey to improve code clarity and remove 'ambiguity of intent' found in typeless or softly typed code.

Lint Hard turns many of the common runtime errors into compile time errors. The rule of thumb is that it is 10 times harder to fix a runtime error than a compiler error. Lint Hard will save you time and frustration.

Using Lint Hard will require you to do a little more work as you code but will significantly reduce runtime errors saving far more time than you will spend cleaning your lints. The dart fix command also automates fixing many of the most common lints reducing the workload.

Lint Hard forces you to use consistent standards across your code base which makes it easier for other developers to read your code. It will also help when you come back to your code in 12 months time.

drop in replacement

You can use Lint Hard as a drop in replacement for your existing lint package (pedantic, lints, flutter_lints ...).

what lints are included

Lint Hard includes every non-clashing dart lint and enables strong mode type checks.

strong-mode:
    implicit-casts: false
    implicit-dynamic: false

You can see the full set of lints in the analysis_options.yaml file.

other improvements

The Lint Hard project also offers the following advice to help you improve the overall quality of your project.

Or you can just jump to the bottom of this page to install Lint Hard.

dart format

We strongly recommend that you use dart format to format your code. Whilst personally I don't like some of the formatting decisions imposed by dart format, consistency is more important. Don't fight this one. Just run dart format with no options. You will get used to the format and it makes sharing code with other developers easier. Using dart format will also make it easier for you to read other developer's code as dart format is almost universally used in the Dart community.

dart format will improve your commit history as it won't be fouled with format differences. This is particularly important in a team project but will render dividends even if you work alone.

Use an IDE like vs-code that automatically formats your code each time you save it.

Only commit code that has been formatted.

a word to JavaScript developers

If you are coming from the JavaScript world, enforcing type declarations may initially feel burdensome but you will quickly see that it allows you to develop faster and release quality code sooner.

avoid dynamic and Object types

For the most part you should never use the dynamic type and rarely use the Object type.

There are exceptions to these rules such as when parsing json dart. But you should always try to use an actual type. dynamic and Object should be last resorts.

Adjustements for package developers

If you are building a dart package then you should be adding documentation to all of your public methods. To ensure you do this consistently add the following to you analysis_options.yaml:

linter: rules: public_member_api_docs : true

Use nnbd

This one probably doesn't need to be said, but just in case...

If you haven't already moved your project to Not Null by Default (nnbd) now is the time to do it. We do recommend applying Lint Hard to your project first and then doing the nnbd conversion. A cleaner code base will help the nnbd migration tool.

Now you have nnbd enabled, try to minimize the use of '?' operator. Use non-nullable types as your default. Only use a nullable type if the variable really needs to be nullable.

Use techniques such as default values and (carefully) the late keyword.

installing Lint Hard

To install lint_hard into your app or package:

Check in any existing code changes.

run dart format

 dart format

Check in the formatted code

If you already use dart format you can skip this step. If you don't currently use dart format this step will make it easier to diff your lint changes as they won't be mingled with format changes.

In a terminal, located at the root of your package, run this command:

dart pub add --dev lint_hard

Create or modify the analysis_options.yaml file in the root of your project:

include: package:lint_hard/all.yaml

Remove your existing linter

If you are using another linter such as lints, pedantic, flutter_lints etc. now is the time to remove it. Your existing lint package should be listed in the dev_dependencies section of your projects pubspec.yaml.

If you have been using the pedantic package it may be in the dependencies section. Remove it also.

run dart fix

The dart fix command will apply a number of automated fixes based on the lint_hard settings.

Run:

 dart fix --apply

Re-run dart fix until it reports 'Nothing to fix!'

run dart format

Finally run dart format over your code. Ideally you should be using an IDE that automatically formats your code whenever you save.

avoid_print for Flutter users

Flutter users may want to add the following to your project's analysis_options.yaml

 linter:
   rules:
     avoid_print: true  

customizing the predefined lint sets

You can customize the predefined lint set, both to disable a lint or to add additional lints. For details see [customizing static analysis].

Use this package as a library

Depend on it

Run this command:

With Dart:

 $ dart pub add lint_hard

With Flutter:

 $ flutter pub add lint_hard

This will add a line like this to your package's pubspec.yaml (and run an implicit dart pub get):

dependencies:
  lint_hard: ^2.1.0

Alternatively, your editor might support dart pub get or flutter pub get. Check the docs for your editor to learn more.

Download Details:

Author: Onepub-dev
Source Code: https://github.com/onepub-dev/lint_hard 
License: BSD-3-Clause license

#flutter #dart #lint

Exceptions and Exception Handling in C#

C## and the .NET CLR use exceptions to show that an error condition has arisen during program execution. C## programs are under constant threat of running into some sort of problem. As a program’s complexity grows, the probability that something odd would happen during its execution also gets higher.

In this blog, we will go through the basics of Exception and Exception handling. We will also look at how we can achieve exception handling using try, catch, and finally blocks and how to create your own custom exceptions.

Exception

The errors which we are getting at the run time of the application is called an exception.

If any exception is coming into our application then the application is abnormally terminated. The Application is not considered as a good application if any exception is coming and it is not handled.

Every time when we are developing an application and it got successfully build without any errors. Then this happens

For that, it is good practice to use exception handling.

#c# #exception #exception handling #.net #exception handling best practices #c++

Exception Handling in Java: Contingencies vs. Faults

When and how to use checked and unchecked exceptions

Introduction

Since the invention of the Java language, there has been a long-standing debate about checked versus unchecked/runtime exceptions. Some people argue that checked exceptions promote a better design. Others feel that checked exceptions get in the way, especially as systems mature and refactor over time, and therefore unchecked exceptions are better. The Effective Java Exceptions article settles this debate once and for all: both checked and unchecked exceptions are acceptable, and each has its purpose within an application. I highly recommend reading that article. I will refer back to its concepts and terminology going forward.

#java #exception handling #exception handling in java #exception in java

Exception Handling in Java Example | Java Exception Handling

In Java, the program that is coded by the programmer can be used in a very unexpected way by the user, due to this, the program may fail in different sort of ways during execution. The main objective of a programmer should be to write a code that does not fail unexpectedly. That unexpected stopping of the program while execution is known as an exception, it disrupts the normal execution flow of a program.

Exception Handling in Java Example

An exception is an event that interrupts the normal flow of execution. It is a disruption during the execution of the Java program. The Exception Handling in Java is one of the powerful mechanisms to handle runtime errors so that the normal flow of the application can be maintained. Let’s see the difference between Error v/s Exception.

#java #exception #java exception handling

STOP throwing Exceptions! Start being Explicit

Exceptions are like landmines in your codebase. Consumers/callers have no idea what you might throw. Top level try/catch aren’t the answer. Start being explicit about the return type of your methods.

🔔 Subscribe: https://www.youtube.com/channel/UC3RKA4vunFAfrfxiJhPEplw?sub_confirmation=1

💥 Join this channel to get access to source code, demos, and slides!
https://www.youtube.com/channel/UC3RKA4vunFAfrfxiJhPEplw/join

📝 Blog: https://codeopinion.com/stop-throwing-exceptions-start-being-explicit/

📚 Book Recommendations

Domain-Driven Design
https://amzn.to/2QwG8sb

Patterns of Enterprise Application Architecture
https://amzn.to/3d8kMJj

Refactoring: Improving the Design of Existing Code
https://amzn.to/2NVdP5Q

Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith
https://amzn.to/3srUuZ6

RESTful Web Clients: Enabling Reuse Through Hypermedia
https://amzn.to/3d8Q96B

CodeOpinon: https://codeopinion.com
Twitter: https://twitter.com/codeopinion

#exceptions #throwing exceptions