"Posso comecar minha proxima customizacao em TLPP?" e a pergunta que todo dev novato faz na consultoria. A resposta nao e "sempre" nem "nunca" — e "depende", com criterios objetivos. Esse artigo entrega esses criterios.

Historico em 30 segundos

timeline title Linguagens TOTVS Protheus 1995-2008 : AdvPL classico : xBase + extensoes : sintaxe Clipper 2008-2018 : AdvPL "moderno" : MVC : OO basica : continua xBase no nucleo 2019-2022 : AdvPL++ : tipagem opcional : tentativa de modernizar 2023+ : TLPP : namespaces : tipagem forte : interop com AdvPL : sintaxe estilo C-like

TLPP (TOTVS Language for Protheus Platform) nao substitui AdvPL. Roda no mesmo runtime. Coexiste no mesmo RPO. Voce pode chamar funcao TLPP de codigo AdvPL e vice-versa.

Comparacao tecnica detalhada

CaracteristicaAdvPL classicoTLPP
NamespacesNao tem (prefixos por convencao)Sim, hierarquicos
TipagemDinamica (opcional)Forte e explicita
Tamanho de identificador10 charsIlimitado
OOClass basicaClass + interface + heranca multipla
ModulosTudo globalModular por namespace
Stack traceLimitadoCompleto com line numbers
Rest annotationsManualDecorators @Get @Post
Compatibilidade SmartClient100%100% (gera mesmo bytecode)
Suporte oficial novoManutencaoFoco da TOTVS daqui pra frente
Curva de aprendizado time AdvPL—~2-4 semanas

3 cenarios onde AINDA usar AdvPL classico

  1. Manutencao de codigo legado: 200k linhas de AdvPL no cliente, ninguem vai reescrever do zero. Mantenha em AdvPL e isole modulos novos em TLPP.
  2. Customizacao de relatorios antigos (RDMAKE/Report): muitas APIs especificas ainda exigem AdvPL puro.
  3. Equipe sem tempo de treinar agora: melhor codigo AdvPL bem escrito do que codigo TLPP ruim. Programe a transicao pra Q3/Q4.

5 cenarios onde MIGRAR pra TLPP

  1. Customizacao nova grande (>500 LOC): namespaces poupam horas em conflito de nomes.
  2. API REST nova: decorators TLPP @Get/@Post reduzem boilerplate em ~60%.
  3. Integracao com sistema externo: tipagem forte previne bug de "cString virou cNumber".
  4. Time grande (3+ devs): namespaces evitam que 2 pessoas criem U_FAT_001 diferentes.
  5. Codigo critico (fiscal, financeiro): stack trace completo + tipagem reduz incidentes em producao.

Migracao gradual: namespaces e interop

Voce nao precisa migrar tudo. O segredo: arquivo .tlpp coexiste com .prw no mesmo RPO. TLPP chama AdvPL como funcao normal:

// arquivo: src/archtec/fiscal/CalculadoraIBS.tlpp
namespace archtec.fiscal

#include "tlpp-core.th"

@type class
class CalculadoraIBS
    private data nAliquota as numeric

    public method new(nAliq as numeric) as CalculadoraIBS
        ::nAliquota := nAliq
    return self

    public method calcular(nValor as numeric) as numeric
        local nResultado as numeric

        // Pode chamar funcao AdvPL classica daqui:
        nResultado := nValor * (::nAliquota / 100)
        nResultado := U_AjustarArredondamento(nResultado)  // funcao AdvPL legacy
    return nResultado
endclass

E o AdvPL classico chama TLPP via namespace explicito:

// arquivo legado: src/legacy/MATA001.prw
#include "totvs.ch"

User Function ProcessaPedido(cNumPed)
    Local oCalc
    Local nIBS

    // Instancia classe TLPP a partir do AdvPL
    oCalc := archtec.fiscal.CalculadoraIBS():New(8.6)
    nIBS := oCalc:calcular(1000)

    // continua codigo legacy normal
Return Nil

Benchmarks reais (loops + REST + DB)

Mesma logica em AdvPL puro vs TLPP, com Protheus 12.1.2410 + DBAccess homologado:

CenarioAdvPL classicoTLPPDelta
Loop 100k iteracoes (calculo simples)1.42s1.45s+2% (irrelevante)
Insert em loop 10k (mesmo codigo)5.8s5.9s+1.7%
API REST endpoint /pedido180ms175ms-3%
Parsing JSON com 50 campos22ms14ms-36%
Compile time (10k linhas)4.2s5.8s+38%

Conclusao do benchmark Em runtime, TLPP esta empatado ou ligeiramente mais rapido (parsing JSON e endpoints REST). O custo esta no compile time — irrelevante em pipeline de CI, importante em desenvolvimento local. Dev produtivo em TLPP usa hot-reload da TOTVS.

Erros tipicos de quem migra rapido demais

Erro 1 Reescrever modulo inteiro de uma vez. Resultado: 2 meses sem entrega + bug em producao. Faca por feature, nao por modulo.

Erro 2 Importar tudo do AdvPL pro TLPP literalmente. TLPP tem padroes melhores (composition over inheritance). Aproveite a refatoracao.

Erro 3 Ignorar tipagem ("e dinamica mesmo, nao precisa"). O ganho do TLPP e justamente a tipagem. Se voce escreve any em tudo, esta no AdvPL com mais boilerplate.

Erro 4 Build sem TLPP-lint. Codigo TLPP sem linter regride pra qualidade de AdvPL classico.

Receita para a equipe: stack de qualidade

  1. VSCode + extensao oficial TLPP (autocomplete + hot reload)
  2. tlpp-lint com regras estritas no projeto
  3. Git Flow ou GitHub Flow + protecao de branch main (sem commit direto)
  4. CI/CD (veja nosso artigo de pipeline)
  5. Code review obrigatorio em PRs maiores que 20 linhas
  6. TIR com cobertura minima de 70% em codigo novo
  7. Documentacao em Markdown dentro do repositorio (nao em Confluence)

Roadmap recomendado pra 2026-2027

FasePeriodoAcao
1. Pilot1 mes1 dev escreve 1 modulo novo em TLPP. Validar ferramentas.
2. Treinamento2 mesesTime inteiro em curso TLPP + lint configurado
3. Padroes1 mesDocumentar convencoes (namespace, classe, teste)
4. ProducaocontinuoCodigo novo sempre em TLPP. Legacy AdvPL so se mexer.
5. Migracao oportunista2-3 anosCada vez que tocar codigo legado, migra modulo.

Em 24 meses voce tem ~70% do projeto em TLPP sem nenhum freeze de feature. Os outros 30% (codigo morto/raramente tocado) seguem AdvPL e nao incomodam ninguem.

Fale conosco se quer ajuda pra montar a stack TLPP da sua equipe.

Sua empresa esta preparada?

Nossa consultoria especializada em TOTVS Protheus pode acelerar sua adequacao.

Falar com Especialista