Skip to content
This repository has been archived by the owner on Apr 21, 2021. It is now read-only.

use sigil s for readability #21

Merged
merged 1 commit into from
Jun 21, 2015
Merged

use sigil s for readability #21

merged 1 commit into from
Jun 21, 2015

Conversation

Joe-noh
Copy link
Contributor

@Joe-noh Joe-noh commented Jun 21, 2015

Hi, sorry but this is an nit-picking pull request.

Sigil string is more readable than string which has many backslashes, isn't it?

note to make sure:

iex(1)> ~s("""\n) == "\"\"\"\n"
true
iex(2)> ~S("""\n) == "\"\"\"\n"
false))
@lpil
Copy link
Owner

lpil commented Jun 21, 2015

Good call! This project is entirely about nit-picking.

There should be a Rule for this. :)

May I ask how you found my new little project? Also, do you have any feedback? I love linters, but I've never written one before!

lpil added a commit that referenced this pull request Jun 21, 2015
@lpil lpil merged commit 0cfb861 into lpil:master Jun 21, 2015
@Joe-noh
Copy link
Contributor Author

Joe-noh commented Jun 21, 2015

Thank you for merging!

May I ask how you found my new little project?

I found your project on "New Packages"; bottom left of hex.pm.
I sometimes look on there.

do you have any feedback? I love linters, but I've never written one before!

Unfortunately I have never written linter too. but I think it is good to imitate rubocup or to refer to José Valim's code for now. Followings are rules that come to my mind.

  • Using pipe for single-argument-single-function-call is not preferred. write foo(var), not var |> foo.
  • Vertical alignment of =, |>, ->, do: and some.
  • CamelCase for module names.
  • snake_case for variable, function and module attribute names.
  • Checking whether there are (at)moduledoc, (at)spec and so on.

In the future, should have a feature to configure detailed parameters by config.exs.

I guess this is the first linter project for elixir.
I'm counting on you. Thank you!

@Joe-noh Joe-noh deleted the joe-noh-sigil-s branch June 21, 2015 22:04
@lpil
Copy link
Owner

lpil commented Jun 22, 2015

Configuration via config.exs would be easier, but I was thinking that maybe it would be good to use a dotfile like rubocop and jshint, as this would allow you to customise your config globally which makes using the liner outside of a mix project nicer.

I'm currently leaning towards config.exs, in part because there's no obvious way of installing hex packages globally.

Do you have any opinions?

@Joe-noh
Copy link
Contributor Author

Joe-noh commented Jun 22, 2015

I think following design is simple, least astonishment.

  • dogma is installed as project deps (only: :dev).
    • don't need to install globally.
  • global setting file is ~/.dogma.exs.
    • It is pretty good if initializing task like mix dogma.global.init is provided.
  • config/confg.exs imports global setting file at first
    • Configuration which comes after the import, local project configuration, overwrites global one.

there's no obvious way of installing hex packages globally.

Just so you know, it is not impossible. Phoenix does with mix archive.install. http://www.phoenixframework.org/v0.13.1/docs/installation.

@lpil lpil mentioned this pull request Jun 22, 2015
@lpil
Copy link
Owner

lpil commented Jun 22, 2015

I like your suggestions! And I didn't know Phoenix did that- good to know.

Thank you for your feedback and support :)

lpil added a commit that referenced this pull request Jul 2, 2015
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants