LibreOffice, mais de 30 mil linhas retiradas
Enviado por Revol (revol·codeΘyahoo·com):
“E o desenvolvimento do LibreOffice continua, basta observar a lista de discussão dos desenvolvedores que você vai ver mais patches enviados e aceitos do que discussões.
E hoje foram lançadas na lista algumas informações interessantes sobre como o projeto estava e como ele está agora em número de linhas. No começo, quando foi feito o fork, eram 5.671.099 linhas e hoje estamos com 5.638.347, isso mostra que os desenvolvedores já retiraram mais de 30 mil linhas de códigos.” [referência: lists.freedesktop.org]
• Publicado por Augusto Campos em
2010-11-17
@brlinuxblog
Feed RSS
bom saber que estão fazendo algo realmente interessante…
Deve ser a parte em java (só estava ali por parte da sun) que está encolhendo…
Não entendi qual a vantagem de tirar as linhas de código
:(
@Ivan Porque são linhas *inúteis*, parte do desenvolvimento é remover o “código-lixo” para facilitar a adição de recursos e a legibilidade do código.
Para ver o que foi retirado, basta abrir o link de referencia da noticia.
Para quem esta achando que estão expurgando o Java, estão enganados, a quantidade de linhas em Java aumentou, apenas 45 linhas mas aumentou.
O que mais fez o LibreOffice emagrecer foi a parte escrita em C++ e C Ansi, daí foram retiradas mais de 16k e mais de 13k linhas respectivamente.
Estou gostando de ver a evolução do código, estão priorizando a retirada de partes obsoletas para depois crescer de forma mais limpa.
Precisava mesmo “enxugar” a suite. Ela tem muita mais linhas do que o Kernel. É um trabalho difícil e demorado mas os resultados serão bons.
[modo discurso político on]
@Ivan, código legado, código mal-feito, funcionalidades refatoradas (reaproveitamento de código ajuda a reduzir o número de linhas de código), remoção de funcionalidades que já não servem pra nada ou não funcionam e ninguém precisa delas, enfim, há muita coisa que pode reduzir o número de linhas de código de uma aplicação.
Lembrando que um grande número de linhas não implica num software melhor. No máximo, mais complexo. E complexidade, principalmente quando se visa resolver um problema simples, quase sempre é ruim.
No lado oposto nem sempre ter um código pequeno é melhor que ter um código maior, pois um código pequeno que não trate todos os casos que um grande trata será sempre pior que este.
Em resumo, o melhor código é sempre aquele enxuto, claro, onde cada linha faça sentido dentro do escopo do problema que pretende resolver.
[modo discurso político off]
Agora falando sério, espero que os desenvolvedores do LibreOffice usem um sistema de compilação mais moderno, tipo cmake.
Fiz a contagem aqui no clone do repositório do LO na minha máquina:
cpp: 4736686 (83.02%)
java: 403890 (7.08%)
xml: 187110 (3.28%)
ansic: 121228 (2.12%)
pascal: 103360 (1.81%)
perl: 77262 (1.35%)
sh: 24069 (0.42%)
python: 18106 (0.32%)
cs: 15907 (0.28%)
yacc: 7526 (0.13%)
lex: 2988 (0.05%)
asm: 2918 (0.05%)
objc: 1728 (0.03%)
lisp: 947 (0.02%)
awk: 807 (0.01%)
php: 593 (0.01%)
csh: 277 (0.00%)
sed: 9 (0.00%)
OpenSUSE M3 versão de desenvolvimento já tirou o OOo e Libre é padrão assim como o Kernel .37
@tenchi, o OpenOffice está mudando pro gnumake2
http://blogs.sun.com/GullFOSS/entry/gbuild_to_boldy_go_where
A coisa tá caminhando pros dois produtos ficarem incompatíveis em questão de código.
Vai ser positivo gerar concorrência entre eles, só espero que não fragmente o suporte ao ODF.
Quanto às linhas de código, o OO tem muito código legado mesmo:
- compatibilidade com o Mozilla antigo (não o Seamonkey, mas o velho mozilão)
- exportar pra Netscape Navigator (quem?)
- gerar código HTML 3.2
- compatibilidade com OO 1.0 ou com o antigo StarOffice
- suporte à integração com motores de busca antigos: Lycos, AltaVista, Excite, …
Fora que muita coisa que o OO implementa que as interfaces gráficas do Windows, Mac e Linux já possuem, bastava usar os nativos do SO. Talvez quando fizeram não existiam os widgets em todas as plataformas, ou então eles queriam o mesmo comportamento pra todos os SOs.
@marcosalex, um dos medos dos desenvolvedores do LO com relação à toolkit é usar Qt no Linux (ou mesmo em todas as plataformas) e depois serem prejuducados pq o Qt é (na verdade era) desenvolvido por uma só empresa, a Nokia (sim, depois do trauma Sun/Oracle…). Atualmente o Qt é mais comunitário que pertencente à uma só empresa, então penso que ele seja uma ótima escolha.
É claro que mudar o toolkit de uma aplicação tão complexa quanto o Openffice, que não é baseado em backend/front-end, o que significa que existe muita “lógica de negócios” misturado com interface gráfica, é um trabalho hercúleo.