Js-beautify: Suporta primeiro estilo de vírgula de declaração de variável

Considerando que oferecemos suporte a JS e Python, o patch (que está seriamente desatualizado) está incompleto, na melhor das hipóteses.

Estamos abertos a solicitações de pull, mas pessoalmente considero "primeiro a vírgula" um antipadrão. Em sua essência, o js-beautifier é opinativo sobre como o JS deve ser, com opções razoáveis ​​que estão em conformidade com o JS "idiomático" amplamente aceito. Em minha opinião, a vírgula primeiro não é bonita, nem é amplamente aceita. Além do mais, isso complicará severamente o código do embelezador (que já é incrivelmente complicado) com muito pouco ganho.

Com indent=4 definido, qual recuo é apropriado? Do ponto de vista da consistência, eu argumentaria o seguinte:

var a = 1
    , b = "foo"
    , c = false;

Que claramente não é a saída esperada. E como ficaria com recuos de tabulação?

Onde vive o ponto e vírgula? No fim? Lugar algum? (Eu vi os dois e mais)

Esta essência está igualmente desatualizada, mas facilita a compreensão da alteração desejada: https://gist.github.com/nemtsov/2864266/revisions

Isso é semelhante ao # 80, então pensei que as razões para isso poderiam ser as mesmas - mais fácil diferenciar e reordenar.

Mas, neste cenário, ao contrário do # 80, há uma solução alternativa viável que atende a esses requisitos:

var a = 1;
var b = "foo";
var c = false;

É um pouco mais prolixo, mas não horrendo.

Obviamente, se alguém implementar o # 80, a alteração mais simples provavelmente também cobrirá esse cenário.
Como @evocateur disse, solicitações de pull são bem-vindas.

@evocateur : Você tem direito à sua opinião e eu respeito isso. Pessoalmente, sempre não gostei do primeiro estilo de vírgula, mas ao longo dos anos, passei a apreciar a facilidade de mover, tirar (comentar, excluir etc.) e como @bitwiseman diz - diferenciar. Portanto, estou disposto a deixar isso como uma opção e deixar o usuário fazer o que preferir. Às vezes, não está em suas mãos e ele tem que seguir padrões já estabelecidos. Sim, feio, mas realidade!

@bitwiseman : Em qualquer nível de indentação (2 ou 4), acho que deve ser assim:

var a = 1
  , b = "foo"
  , c = false;

Acho que isso também é consistente com a forma como alguns editores de SQL (onde a vírgula é mais predominante) fazem isso.

E embora eu não esteja defendendo a promoção de layouts ruins, acho que sempre há uma linha tênue entre ser idiomático e dogmático (pense em Crockford aqui). A vírgula primeiro pode não prevalecer porque muitos dos formatadores não a suportam, seja qual for o motivo.

Você está mais familiarizado com o estado das coisas em termos de código, então concordo perfeitamente com seu argumento de ROI. Mesmo assim, pensei em pedir para que possamos divulgar essas coisas, ter um quórum para discutir as coisas e se houver demanda da comunidade, talvez vocês possam repensar sobre isso.

PS Passei algumas horas tentando ver se consigo criar algo rapidamente e não tive muito sucesso. Talvez eu tente outra hora.

@mrchief Minhas desculpas por ter sido rude ontem, eu estava fazendo uma pausa em uma sessão de depuração frustrante. Você fez boas observações e quero deixar claro que também respeito sua escolha. Eu mesmo tento manter o estilo de um determinado projeto se estou contribuindo com um patch (primeiro vírgula, sem ponto-e-vírgula, outras maluquices) e concordo que opções como essas podem no mínimo ajudar a reforçar um pouco de consistência nos projetos que optam por empregá-los.

+1. Eu uso o padrão de vírgula primeiro por suas vantagens ao diferenciar e mesclar.

Quanto à posição do ponto-e-vírgula: coloquei em uma nova linha, de acordo com a palavra-chave var , assim:

var a
  , b
  , c
;

Já vi vários projetos que usam o mesmo padrão.

Além disso, IMHO, acho que seria bom ser capaz de manter cada variável em uma linha separada, embora um valor não seja fornecido ao lado da declaração. No exemplo acima, o embelezador agruparia tudo em uma linha var a, b, c; que também quebra todo o propósito de usar o estilo de punho de vírgula.

+1 para suporte primeiro com vírgula.

No recuo de 2 espaços, é a maneira mais organizada de organizar as variáveis:

var foo = true
  , bar = 'hello'
  , something;

Que tal 4 espaços por guia? Guias reais?

Na sexta-feira, 8 de novembro de 2013 às 9h36, Luke Martin [email protected]
escreveu:

+1 para suporte primeiro com vírgula.
No recuo de 2 espaços, é a maneira mais organizada de organizar as variáveis
var foo = true
, bar = 'olá'

, algo;

Responda a este e-mail diretamente ou visualize-o no GitHub:
https://github.com/einars/js-beautify/issues/245#issuecomment -28081629

Eu acho que o ponto crucial da questão da vírgula na verdade se resume à preferência de tabulação.

Eu uso tabulações de 2 espaços e vírgula antes é a única maneira de organizar variáveis ​​sem adicionar espaços em branco desnecessários (~ representam espaços extras adicionados para alinhar as coisas):

// eww
var foo = true,
  ~~bar = 'hello',
  ~~something;

// yum
var foo = true
  , bar = 'hello'
  , something;

Por outro lado, se você usar tabulações de 4 espaços, a vírgula antes ficará ruim e você naturalmente não se importará com o suporte para ela.

// also eww
var foo = true
    , bar = 'hello'
    , something;

Portanto, há uma discussão sobre a vírgula - antes de ser mais fácil comentar e depurar e blá-blá-blá. Mas para mim, tudo se resume à estética. Eu uso guias de 2 espaços, então preciso usar vírgula antes. Atualmente não posso usar o embelezamento porque tenho preferência por guias de 2 espaços.

Agora eu sei que provavelmente estou em uma minoria, e absolutamente não estou exigindo apoio para minha pequena preferência. Eu estava apenas adicionando meu +1 à conversa. Posso até pensar em adicionar suporte sozinho, se tiver tempo.

Saúde :)

Eu gostaria de ver isso para objetos JSON.

 var a = ({
 a: 1
 , b: 2
 });

@lukemartin Essa é uma perspectiva interessante! : +1:

Outro +1 para suporte a vírgula primeiro, para declaração de variável, bem como array e objetos - https://gist.github.com/isaacs/357981

Estou trabalhando em um patch para oferecer suporte a esse recurso "sob demanda" (o usuário pode habilitar ou desabilitar a opção de usar vírgula primeiro com uma configuração que criei).

Consegui a seguinte formatação para declaração de variável (usando 2 espaços):

var firstVar = 1
  , secondVar = 2
  , thirdVar = 3
;

Mas tenho algumas dúvidas.

Como devemos tratar matrizes, objetos e declarações de argumentos? Ultimamente, tenho usado o seguinte formato:

myArray = [
  item1
, item2
, item3
];

myObject = {
  prop1: 1
, prop2: 2
, prop3: 3
}

Que, como você pode ver, não é exatamente o mesmo que a formatação da declaração da variável: esta última inclui um nível de recuo +1 para a segunda variável (observe os dois espaços antes da vírgula que não estão presentes antes da vírgula para "item2" nem para o "prop2"). As declarações de Var usam este recuo extra para alinhar na mesma coluna o início de cada nome de variável conforme declarado por @lukemartin.

Os motivos para usar a formatação mostrada no código acima são:

1.- Para evitar os erros de linting que seriam lançados pelo jshint (erros de indentação). Por exemplo:

myArray = [
    item1
  , item2
];

Lança "Esperado] para ter um recuo em 3, em vez de 1". Se seguirmos a sugestão, obtemos um resultado muito feio.

2.- Manter a vantagem de alinhar o início de cada nome de propriedade, item do array, etc. Por exemplo:

myArray = [
  item1
  , item2
];

Também não produz um erro de linting, mas não parece tão bom quanto os exemplos acima.

Com uma ideia mais clara de como devo tratar esses casos, poderia terminar a implementação deste recurso e emitir um Pull Request.

É possível apoiar todos os itens acima? Tudo o que você listou é tecnicamente "vírgula primeiro".

Acredito que seja possível, mas seria necessário implementar mais configurações que permitissem ao usuário atingir o resultado desejado. Por exemplo, seria necessário informar ao formatador se você deseja usar 2 níveis de indentação para matrizes, objetos e argumentos ou apenas um.

Acho que seria melhor atingir a funcionalidade básica primeiro e, em seguida, estendê-la com mais configurações. Acredito que não teria nenhum problema em implementá-los em um segundo patch.

Como você disse, a funcionalidade básica está bem. É um _não_ objetivo_ deste projeto oferecer suporte a _todas_ opções de formatação. :sorriso:

// 2-space indents
var itemA = 1
  , itemB: 2
  , itemC: 3;

myObj = {
  itemA: 1
  , itemB: 2
}

myArray = [
  item1
  , item2
];

// 4-space indents
var itemA = 1
    , itemB: 2
    , itemC: 3;

myObj = {
    itemA: 1
    , itemB: 2
}

myArray = [
    item1
    , item2
];

Eles devem manter seu código simples, a formatação consistente, não importa quais recuos sejam usados, e nos permite encerrar esse problema e abrir um novo problema para "Colunizar identificadores de vírgula primeiro" (ou qualquer outro) que pode ser especificado e implementado separadamente .

Estou ansioso para ver sua solicitação de pull!

@tgirardi Ótimo trabalho. Mal posso esperar para experimentar.

Todos os comentários são bem-vindos :-) !!!

Minha ideia é ajustar o código até que seja considerado a solução correta e então prosseguir com a seguinte lista TODO:

1.- Crie testes para este novo recurso
2.- Aplicar recurso na versão Python (se alguém se voluntariar para isso, melhor ainda! ... Não tenho muita experiência com python).
3.- Discuta outras variações possíveis de estilos primeiro com vírgula

Recuo de 4 espaços

var x = a
    , y = b
;
obj = {
    attr1: "value1"
    , attr2: "value2"
    , attr3: "value3"
};

Os nomes de variáveis ​​e nomes de atributos não precisam ser alinhados. Isso não afeta a legibilidade de forma alguma. Em minha opinião, o principal motivo para usar primeiro a coluna é tornar mais fácil comentar, remover e inserir linhas. Acontece apenas de alinhar ao usar recuo de 2 espaços.

A ponto-e-vírgula deve estar em sua própria linha após a declaração de várias variáveis ​​para facilitar o acréscimo de uma nova variável após 'y'. Neste caso, no VIM, 'o' + ', z = c' em vez de '$ a,'+' z = c '

@lewisdiamond Concordo com seu comentário em ponto-e-vírgula. Tê-lo em sua própria linha garante que a última variável também possa ser facilmente editada (remover, substituir, inserir linha depois / antes, etc).

Mas também foi observado que:

1.- Não é objetivo do projeto suportar todos os tipos de formatação.
2.- Adicionar muita complexidade de uma vez é uma má ideia. Portanto, poderia ser melhor manter este recurso o mais simples possível primeiro e começar a melhorá-lo depois que ele atingir um estado de lançamento e tiver sido testado por algum tempo

+1 para suporte primeiro a vírgula, e eu concordo com a opinião de lewisdiamond de que garantir que as guias sejam alinhadas corretamente não deve ser o objetivo final, pois há razões pragmáticas para o estilo primeiro vírgula. Eu adoraria suporte para json também. Atualmente eu tenho um hack no código js-beautify global para fazer um monte de alternativas de pontuação primeiro (para operadores ternários era uma obrigação).

Para todos que marcaram isto com +1: por favor, dê uma olhada no branch https://github.com/beautify-web/js-beautify/tree/feature/comma-first .

Diga-me se este é um primeiro passo suficiente para o que você deseja que eu devo adicioná-lo ao próximo lançamento.

@olsonpm , @lewisdiamond , @lukemartin , @mrchief - vocês poderiam dar uma olhada no branch https://github.com/beautify-web/js-beautify/tree/feature/comma-first .

Vou gastar 30 minutos nisso esta noite e responder com pensamentos. Obrigado por acompanhar.

Cheguei a isso esta manhã. Tudo parece bom para mim devido aos seus testes. Eu tenho um branch pessoal com muitas funcionalidades de primeiro operador - eu coloquei meus testes de vírgula em seu branch e todos eles passaram sem problemas, o que é uma ótima notícia.

Quando criei meu branch pessoal, decidi que o operador vírgula seria passivo, o que significa o seguinte:

var a,
    b;

não seria alterado. Você afirmou claramente que este não é o caso na mensagem de commit, eu apenas sinto que vale a pena discutir com os outros o comportamento que eles esperariam se escolhessem usar opt.comma_first.

Outra coisa, <Output> .previous_line e flags.previous_text são as mesmas coisas que eu acredito, o que foi confuso para mim no início, mas fazia sentido na forma como você os usava.

Fora isso, a principal diferença entre nossas implementações é que você optou por modificar a linha anterior. Eu estava tentando não "voltar e editar as coisas" porque achava que era mais confuso desenvolver. Agora o seu jeito é mais conciso do que o meu - é de fácil leitura e você comentou tudo. O código existente também edita tokens anteriores para que seu código fique perfeitamente alinhado - honestamente, estou apenas trazendo isso porque gostaria de saber o que você pensa. Resumindo, minha opinião é que este programa seria muito mais fácil de depurar se os tokens fossem responsáveis ​​apenas pelo espaço em branco à frente deles com base nos próximos tokens.

Obrigado por abordar isso!

Edit: Meu erro - <Output> .previous_line e flags.previous_text são completamente diferentes.

Somente para frente é preferível. Eu olhei para a bola de cabelo de como e onde decidimos o que fazer com / sobre as vírgulas, já há lugares em que aparamos a saída de volta para colocá-los no lugar certo. Decidi fazer algo um pouco simplista, fazer alguns testes para verificar o comportamento simplista e depois ver como ajustá-lo e refatorá-lo.

O exemplo que você menciona:

var a,
    b;

Seria um exemplo de ajuste que poderia ser discutido mais tarde.

Soa bem. Agradeço o feedback.

E muito obrigado por revisar. Se você tiver algum teste que queira adicionar, será uma grande ajuda.