labs42io / clean-code-typescript Goto Github PK
View Code? Open in Web Editor NEWClean Code concepts adapted for TypeScript
Home Page: https://labs42io.github.io/clean-code-typescript
License: MIT License
Clean Code concepts adapted for TypeScript
Home Page: https://labs42io.github.io/clean-code-typescript
License: MIT License
Help needed to add translations.
We should change the references from TSLint to ESLint as TSLint has been deprecated as of 2019.
See https://palantir.github.io/tslint:
⚠️ TSLint is deprecated.See this issue for more details: Roadmap: TSLint → ESLint. If you're interested in helping with the TSLint/ESLint migration, please check out our OSS Fellowship program.
Hi!
Thanks for your great guide to clean coding with TypeScript! I have created a web "e-book" version of your guide with the HonKit application.
You can check out the web version here: https://tderflinger.github.io/clean-code-typescript-ebook/ and the source code here: https://github.com/tderflinger/clean-code-typescript-ebook
So I wanted to ask if you could add a link to my website. Alternatively, I might create a PR with my changes so you can integrate the version with HonKit into your project. What do you think about that?
Best regards,
-Thomas
Hi,
Could we add the spread operator to this?
function createMenu(config: MenuConfig) {
const menuConfig = {
title: 'Foo',
body: 'Bar',
buttonText: 'Baz',
cancellable: true,
...config,
};
// ...
}
Thanks for your work
Instead of "It will still be safe in your version history if you still need it.", I think it should be "It will still be saved in your version history if you still need it."
want you to incorporate features that you think are personally wonderful entering from typescript 3.4
https://github.com/labs42io/clean-code-typescript#avoid-side-effects-part-1
The const definition does not block rewriting of the contents of object, but you can handle immutable objects by using as const
.
(It can be experienced with typescript 3.4.0-dev)
although tslint is introduced in Formatting, since most tslint rules do not override interface-over-type-literal
and are true
, contents of type vs interface will error .
(confirming, only TSLint Clean Code was false
)
also issues, it may be deleted from tslint: recommended
in future, but it has not disappeared at moment.
Important thing is that if you follow the rules of tslint, will most likely result in an error.
need to set interface-over-type-literal
to false
as a workaround, should prompt for a trade-off with quality.
should I add this as a supplement to type vs interface?
I don't understand this rule in the aspect of why would you add a getter / setter for a simple property with not logic?
The example demonstrates exactly how you can always take a regular property and refactor it easily only within the class to use a getter / setter without editing any of the usage of it (getters and setters act like regular properties outside of the class).
So with this in mind, why would you add getter / setter in advance for simple properties without any logic?
Hi! Thank you for this repo, it is really useful :)
I would like to add a complete example of the use of clean code and clean architecture concepts (by creating for example the backend for a classic note-taking app).
Do you think that could be interesting for the community?
Provide good samples and motivation to use iterators/generators in Functions
section.
Best practices for writing modules with TypeScript
export default
)etc.
Section: Variables
:
I saw in many interviews people that doesn't know that we can access Type['attribute']
like this. In some cases it's good because typescript will show you where code will break. For example
given we have a type Person
type Person = {
id: string;
name: string;
}
many people create specific functions like this
const getPersonName = (id: string) => {}
besides if you change the attribute's type or name it'll not break anything and you'll suffer to find every place to update, but when we use like this below
const getPersonName = (id: Person['id']) => {}
typescript will tell you where code will break.
There's another cases for whose use the entire type for function parameter instead of use Pick/Omit/etc.
Add more samples and description to Objects and Data Structures
about builtin types in TypeScript, like the Partial
, ReadonlyArray
etc.
In the example of "Function arguments (2 or fewer ideally)"
There is a talk about destrcuting, which to what I know is:
const object = {a: 1, b: 2};
const {a, b} = object; // This is destrcuting
Now what the code there does is
function createMenu(options: { title: string, body: string, buttonText: string, cancellable: boolean }) {
// ...
}
createMenu({
title: 'Foo',
body: 'Bar',
buttonText: 'Baz',
cancellable: true
});
I can't find the destructing here (I don't think declaring option type should be considered as destructing.
In the "Set default objects with Object.assign or destructuring" the last example actually does use destructing unlike in this example.
Maybe the paragraph of "Function arguments" should be changed? Or am I missing something here?
Should we cover generics?
Provide samples and explanation when/how to use // TODO
comments (in Comments section).
hi
Could I translate this to Persian language?
I want to trans
`type MenuConfig = { title?: string, body?: string, buttonText?: string, cancellable?: boolean };
function createMenu({ title = 'Foo', body = 'Bar', buttonText = 'Baz', cancellable = true }: MenuConfig) {
// ...
}
createMenu({ body: 'Bar' });`
Crossing the example given in "Set default objects with Object.assign or destructuring" with one of the first rules:
"Function arguments (2 or fewer ideally)
Limiting the number of function parameters is incredibly important because it makes testing your function easier. Having more than three leads to a combinatorial explosion where you have to test tons of different cases with each separate argument."
Isn't this example actually crossing the line of having more than 3 arguments? Logically I feel like the destructing example is with object with more than 3 properties is the same as giving the function more than 3 arguments for the exact same reason specified in this rule. Am I wrong to think this way?
Proposal to add a section with examples about cross-cutting concerns:
Proxy
Reflect
Do not add unneeded context
https://github.com/labs42io/clean-code-typescript#dont-add-unneeded-context
argments is not this.
, is not it a car
?
(sample gives an error)
type Car = {
make: string;
model: string;
color: string;
}
function print(car: Car): void {
console.log(`${car.make} ${car.model} (${car.color})`);
}
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.