cscout

O CSCOUT é um analisador de código -fonte e o navegador de refatoração para coleções de programas C. Ele pode processar espaços de trabalho de vários projetos (um projeto é definido como uma coleção de arquivos de origem C que estão vinculados) mapeando a complexidade introduzida pelo pré -processador C de volta aos arquivos de código -fonte C originais. O CSCOUT aproveita o hardware moderno (processadores rápidos e grandes capacidades de memória) para analisar o código -fonte C além do nível de detalhe e precisão fornecido pelos compiladores e ligantes atuais. O desempenho do CSCOUT da análise leva em consideração os escopos de identificador introduzidos pelo pré -processador C e pelos escopos e namespaces da linguagem C. O CSCOUT já foi aplicado em projetos de dezenas de milhares de linhas a milhões de linhas, como os kernels Linux, OpenSolaris e FreeBSD e o Apache Web Server.

Para mais detalhes, exemplos e documentação, visite o site do projeto.

Construção, teste, instalação, usando

O CSCOUT foi compilado e testado no GNU/Linux (Debian Jessie), Apple OS X (El Capitan), FreeBSD (11.0) e Cygwin. Para construir e usar o CSCOUT, você precisa de um sistema UNIX (como) com um compilador C ++ moderno, GNU Make e Perl. Para testar o CSCOUT, você também precisa instalar o sqlite. Para visualizar os diagramas do CSCOUT, você deve ter o comando GraphViz Dot no caminho do arquivo executável.

• Para construir uma make . Você também pode usar a opção -j fazer aumentar a velocidade da compilação.
• Para construir e testar, execute make test .
• Para instalar (normalmente após a construção e teste), o Run sudo make install .
• Para ver o cScout em ação, make example .

Sob FreeBSD, use gmake em vez de make .

O teste requer uma versão instalada do SQLite .

Contribuindo

• Você pode contribuir para qualquer um dos problemas abertos ou pode abrir um novo descrevendo o que deseja fazer.
• Para melhorias e correções em pequena escala, basta enviar uma solicitação de tração do GitHub. Cada solicitação de tração deve cobrir apenas um único recurso ou correção de bug. O código alterado deve seguir o estilo de código do restante do programa. Se você estiver contribuindo com um recurso, não se esqueça de atualizar a documentação. Se você estiver enviando uma correção de bug, abra um problema do Github correspondente e consulte o problema em seu compromisso. Evite alterações gratuitas de código. Verifique se os testes continuam passando após sua alteração. Se você estiver consertando um bug ou adicionando um recurso relacionado ao idioma, adicione um caso de teste correspondente.
• Antes de iniciar uma contribuição em larga escala, abra um problema do GitHub.